linux.git/arch/powerpc/kernel/setup-common.c, branch v3.17 Linux kernel source tree Merge remote-tracking branch 'scott/next' into next 2014-08-05T04:13:41+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2014-08-05T04:13:41+00:00 9287b95ec9ded0a4458094ebd967502263d80112 Scott writes: Highlights include e6500 hardware threading support, an e6500 TLB erratum workaround, corenet error reporting, support for a new board, and some minor fixes. 
Scott writes:

Highlights include e6500 hardware threading support, an e6500 TLB erratum
workaround, corenet error reporting, support for a new board, and some
minor fixes.
powerpc/e6500: Add support for hardware threads 2014-07-30T00:26:20+00:00 Andy Fleming afleming@freescale.com 2011-12-08T07:20:27+00:00 e16c8765533a155ebd3d7c36fc80440a03bbf46a The general idea is that each core will release all of its threads into the secondary thread startup code, which will eventually wait in the secondary core holding area, for the appropriate bit in the PACA to be set. The kick_cpu function pointer will set that bit in the PACA, and thus "release" the core/thread to boot. We also need to do a few things that U-Boot normally does for CPUs (like enable branch prediction). Signed-off-by: Andy Fleming <afleming@freescale.com> [scottwood@freescale.com: various changes, including only enabling threads if Linux wants to kick them] Signed-off-by: Scott Wood <scottwood@freescale.com> 
The general idea is that each core will release all of its
threads into the secondary thread startup code, which will
eventually wait in the secondary core holding area, for the
appropriate bit in the PACA to be set. The kick_cpu function
pointer will set that bit in the PACA, and thus "release"
the core/thread to boot. We also need to do a few things that
U-Boot normally does for CPUs (like enable branch prediction).

Signed-off-by: Andy Fleming <afleming@freescale.com>
[scottwood@freescale.com: various changes, including only enabling
 threads if Linux wants to kick them]
Signed-off-by: Scott Wood <scottwood@freescale.com>
powerpc: Don't skip ePAPR spin-table CPUs 2014-06-25T03:10:49+00:00 Scott Wood scottwood@freescale.com 2014-06-25T01:15:51+00:00 6663a4fa6711050036562ddfd2086edf735fae21 Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs that aren't presently running shall have status of disabled, with enable-method being used to determine whether the CPU can be enabled. Fix by checking for spin-table, which is currently the only supported enable-method. Signed-off-by: Scott Wood <scottwood@freescale.com> Cc: Michael Neuling <mikey@neuling.org> Cc: Emil Medve <Emilian.Medve@Freescale.com> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup
CPUs with bad status" broke ePAPR SMP booting.  ePAPR says that CPUs
that aren't presently running shall have status of disabled, with
enable-method being used to determine whether the CPU can be enabled.

Fix by checking for spin-table, which is currently the only supported
enable-method.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Emil Medve <Emilian.Medve@Freescale.com>
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Don't setup CPUs with bad status 2014-06-11T07:03:01+00:00 Michael Neuling mikey@neuling.org 2014-06-06T04:28:51+00:00 59a53afe70fd530040bdc69581f03d880157f15a OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU node. Unfortunatley Linux doesn't check this property and will put the bad CPU in the present map. This has caused hangs on booting when we try to unsplit the core. This patch checks the CPU is avaliable via this status property before putting it in the present map. Signed-off-by: Michael Neuling <mikey@neuling.org> Tested-by: Anton Blanchard <anton@samba.org> cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU
node.

Unfortunatley Linux doesn't check this property and will put the bad CPU in the
present map.  This has caused hangs on booting when we try to unsplit the core.

This patch checks the CPU is avaliable via this status property before putting
it in the present map.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Anton Blanchard <anton@samba.org>
cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Merge git://www.linux-watchdog.org/linux-watchdog 2014-06-11T02:16:36+00:00 Linus Torvalds torvalds@linux-foundation.org 2014-06-11T02:16:36+00:00 dfb945473ae8528fd885607b6fa843c676745e0c Pull watchdog updates from Wim Van Sebroeck: "This contains: - addition of the Intel MID watchdog - removal of W83697HF and W83697UG drivers (code was merged into w83627hf_wdt driver) - addition of Armada 375/380 SoC support - conversion of imx2_wdt to regmap API and to watchdog core API - lots of other small improvements and fixes" [ Wim was also tagged by gmail as a spammer, but not delayed by days unlike Ben ] * git://www.linux-watchdog.org/linux-watchdog: (25 commits) x86: intel-mid: add watchdog platform code for Merrifield watchdog: add Intel MID watchdog driver support watchdog: sp805: Set watchdog_device->timeout from ->set_timeout() booke/watchdog: refine and clean up the codes watchdog: iop_wdt only builds for mach-iop13xx watchdog: Remove drivers for W83697HF and W83697UG watchdog: w83627hf_wdt: Add early_disable module parameter ARM: mvebu: Add A375/A380 watchdog binding documentation watchdog: orion: Add Armada 375/380 SoC support watchdog: orion: Introduce per-SoC enabled() function watchdog: orion: Introduce per-SoC stop() function watchdog: orion: Remove unneeded atomic access watchdog: orion: Introduce a SoC-specific RSTOUT mapping watchdog: orion: Move the register ioremap'ing to its own function watchdog: xilinx: Make of_device_id array const watchdog: imx2_wdt: convert to watchdog core api watchdog: imx2_wdt: convert to use regmap API. watchdog: imx2_wdt: Sort the header files alphabetically watchdog: ath79_wdt: switch to clk_prepare/clk_disable watchdog: ath79_wdt: avoid spurious restarts on AR934x ... 
Pull watchdog updates from Wim Van Sebroeck:
 "This contains:
   - addition of the Intel MID watchdog
   - removal of W83697HF and W83697UG drivers (code was merged into
     w83627hf_wdt driver)
   - addition of Armada 375/380 SoC support
   - conversion of imx2_wdt to regmap API and to watchdog core API
   - lots of other small improvements and fixes"

[ Wim was also tagged by gmail as a spammer, but not delayed by days
  unlike Ben ]

* git://www.linux-watchdog.org/linux-watchdog: (25 commits)
  x86: intel-mid: add watchdog platform code for Merrifield
  watchdog: add Intel MID watchdog driver support
  watchdog: sp805: Set watchdog_device->timeout from ->set_timeout()
  booke/watchdog: refine and clean up the codes
  watchdog: iop_wdt only builds for mach-iop13xx
  watchdog: Remove drivers for W83697HF and W83697UG
  watchdog: w83627hf_wdt: Add early_disable module parameter
  ARM: mvebu: Add A375/A380 watchdog binding documentation
  watchdog: orion: Add Armada 375/380 SoC support
  watchdog: orion: Introduce per-SoC enabled() function
  watchdog: orion: Introduce per-SoC stop() function
  watchdog: orion: Remove unneeded atomic access
  watchdog: orion: Introduce a SoC-specific RSTOUT mapping
  watchdog: orion: Move the register ioremap'ing to its own function
  watchdog: xilinx: Make of_device_id array const
  watchdog: imx2_wdt: convert to watchdog core api
  watchdog: imx2_wdt: convert to use regmap API.
  watchdog: imx2_wdt: Sort the header files alphabetically
  watchdog: ath79_wdt: switch to clk_prepare/clk_disable
  watchdog: ath79_wdt: avoid spurious restarts on AR934x
  ...
booke/watchdog: refine and clean up the codes 2014-06-10T19:47:26+00:00 Tang Yuantian yuantian.tang@freescale.com 2014-05-08T02:04:26+00:00 d2deebabaeedccf7cee943c1f7f6fdb44afd4e3d Basically, this patch does the following: 1. Move the codes of parsing boot parameters from setup-common.c to driver. In this way, code reader can know directly that there are boot parameters that can change the timeout. 2. Make boot parameter 'booke_wdt_period' effective. currently, when driver is loaded, default timeout is always being used in stead of booke_wdt_period. 3. Wrap up the watchdog timeout in device struct and clean up unnecessary codes. Signed-off-by: Tang Yuantian <yuantian.tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Reviewed-by: Li Yang <leoli@freescale.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be> 
Basically, this patch does the following:
1. Move the codes of parsing boot parameters from setup-common.c
   to driver. In this way, code reader can know directly that
   there are boot parameters that can change the timeout.
2. Make boot parameter 'booke_wdt_period' effective.
   currently, when driver is loaded, default timeout is always
   being used in stead of booke_wdt_period.
3. Wrap up the watchdog timeout in device struct and clean up
   unnecessary codes.

Signed-off-by: Tang Yuantian <yuantian.tang@freescale.com>
Acked-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Li Yang <leoli@freescale.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
powerpc: Add threads_per_subcore 2014-05-28T03:35:35+00:00 Michael Ellerman mpe@ellerman.id.au 2014-05-23T08:15:27+00:00 5853aef1ac5c5d83076203e840ca463857a7515d On POWER8 we have a new concept of a subcore. This is what happens when you take a regular core and split it. A subcore is a grouping of two or four SMT threads, as well as a handfull of SPRs which allows the subcore to appear as if it were a core from the point of view of a guest. Unlike threads_per_core which is fixed at boot, threads_per_subcore can change while the system is running. Most code will not want to use threads_per_subcore. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
On POWER8 we have a new concept of a subcore. This is what happens when
you take a regular core and split it. A subcore is a grouping of two or
four SMT threads, as well as a handfull of SPRs which allows the subcore
to appear as if it were a core from the point of view of a guest.

Unlike threads_per_core which is fixed at boot, threads_per_subcore can
change while the system is running. Most code will not want to use
threads_per_subcore.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: powernv: Framework to show the correct clock in /proc/cpuinfo 2014-04-28T07:36:38+00:00 Gautham R. Shenoy ego@linux.vnet.ibm.com 2014-03-11T11:31:18+00:00 2299d03a632c7586403ab43a11b418ee1ae47f1a Currently, the code in setup-common.c for powerpc assumes that all clock rates are same in a smp system. This value is cached in the variable named ppc_proc_freq and is the value that is reported in /proc/cpuinfo. However on the PowerNV platform, the clock rate is same only across the threads of the same core. Hence the value that is reported in /proc/cpuinfo is incorrect on PowerNV platforms. We need a better way to query and report the correct value of the processor clock in /proc/cpuinfo. The patch achieves this by creating a machdep_call named get_proc_freq() which is expected to returns the frequency in Hz. The code in show_cpuinfo() can invoke this method to display the correct clock rate on platforms that have implemented this method. On the other powerpc platforms it can use the value cached in ppc_proc_freq. Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
Currently, the code in setup-common.c for powerpc assumes that all
clock rates are same in a smp system. This value is cached in the
variable named ppc_proc_freq and is the value that is reported in
/proc/cpuinfo.

However on the PowerNV platform, the clock rate is same only across
the threads of the same core. Hence the value that is reported in
/proc/cpuinfo is incorrect on PowerNV platforms. We need a better way
to query and report the correct value of the processor clock in
/proc/cpuinfo.

The patch achieves this by creating a machdep_call named
get_proc_freq() which is expected to returns the frequency in Hz. The
code in show_cpuinfo() can invoke this method to display the correct
clock rate on platforms that have implemented this method. On the
other powerpc platforms it can use the value cached in ppc_proc_freq.

Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Make boot_cpuid common between 32 and 64-bit 2014-04-07T00:33:14+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2014-03-28T02:36:27+00:00 36ae37e3436b0c7731ae15a03d9215ff24bef9f2 Move the definition to setup-common.c and set the init value to -1 on both 32 and 64-bit (it was 0 on 64-bit). Additionally add a check to prom.c to garantee that the init value has been udpated after the DT scan. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
Move the definition to setup-common.c and set the init value
to -1 on both 32 and 64-bit (it was 0 on 64-bit).

Additionally add a check to prom.c to garantee that the init
value has been udpated after the DT scan.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc: Fix endian issue in setup-common.c 2013-12-13T04:48:34+00:00 Anton Blanchard anton@samba.org 2013-12-12T04:59:35+00:00 01666c8ee2b6afcd31de2064fbb7c097a75e5089 During on LE boot we see: Partition configured for 1073741824 cpus, operating system maximum is 2048. Clearly missing a byteswap here. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 
During on LE boot we see:

    Partition configured for 1073741824 cpus, operating system maximum is 2048.

Clearly missing a byteswap here.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>