Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit c0e30913 authored by Kevin Hilman's avatar Kevin Hilman
Browse files

Merge tag 'omap-for-v4.6/fixes-rc2-v2-signed' of...

Merge tag 'omap-for-v4.6/fixes-rc2-v2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

Merge "omap fixes against v4.6-rc2" from Tony Lindgren

Fixes for omaps against v4.6-rc2, mostly to fix suspend for beagle-x15
that broke when we added runtime based SoC revision detection earlier.

It seems suspend worked earlier as things were only partially initialized,
while now we initialize things properly for dra7.

Note that the "ARM: OMAP: Catch callers of revision information prior
to it being populated" had to be reverted as it caused bogus warnings
for other SoCs because omap initcalls bail out based on revision being
set to 0 for other SoCs. These initcalls will mostly just disappear
when we drop support for omap3 legacy booting.

Also included is a fix for dra7 sys_32k_ck clock source that is not
enabled on boot making system fall back to using emulated clock.

* tag 'omap-for-v4.6/fixes-rc2-v2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (198 commits)
  Revert "ARM: OMAP: Catch callers of revision information prior to it being populated"
  ARM: OMAP: Catch callers of revision information prior to it being populated
  ARM: dts: dra7: Correct clock tree for sys_32k_ck
  ARM: OMAP: DRA7: Provide proper class to omap2_set_globals_tap
  ARM: OMAP: DRA7: wakeupgen: Skip SAR save for wakeupgen
  Linux 4.6-rc2
  v4l2-mc: avoid warning about unused variable
  Convert straggling drivers to new six-argument get_user_pages()
  .mailmap: add Christophe Ricard
  Make CONFIG_FHANDLE default y
  mm/page_isolation.c: fix the function comments
  oom, oom_reaper: do not enqueue task if it is on the oom_reaper_list head
  mm/page_isolation: fix tracepoint to mirror check function behavior
  mm/rmap: batched invalidations should use existing api
  x86/mm: TLB_REMOTE_SEND_IPI should count pages
  mm: fix invalid node in alloc_migrate_target()
  include/linux/huge_mm.h: return NULL instead of false for pmd_trans_huge_lock()
  mm, kasan: fix compilation for CONFIG_SLAB
  MAINTAINERS: orangefs mailing list is subscribers-only
  net: mvneta: fix changing MTU when using per-cpu processing
  ...
parents 2193a3fd 3d51ae17
Loading
Loading
Loading
Loading
+1 −0
Original line number Diff line number Diff line
@@ -33,6 +33,7 @@ Björn Steinbrink <B.Steinbrink@gmx.de>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Christoph Hellwig <hch@lst.de>
Christophe Ricard <christophe.ricard@gmail.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
David Brownell <david-b@pacbell.net>
+1 −1
Original line number Diff line number Diff line
@@ -386,7 +386,7 @@ used. First phase is to "prepare" anything needed, including various checks,
memory allocation, etc. The goal is to handle the stuff that is not unlikely
to fail here. The second phase is to "commit" the actual changes.

Switchdev provides an inftrastructure for sharing items (for example memory
Switchdev provides an infrastructure for sharing items (for example memory
allocations) between the two phases.

The object created by a driver in "prepare" phase and it is queued up by:
+208 −0
Original line number Diff line number Diff line
x86 Topology
============

This documents and clarifies the main aspects of x86 topology modelling and
representation in the kernel. Update/change when doing changes to the
respective code.

The architecture-agnostic topology definitions are in
Documentation/cputopology.txt. This file holds x86-specific
differences/specialities which must not necessarily apply to the generic
definitions. Thus, the way to read up on Linux topology on x86 is to start
with the generic one and look at this one in parallel for the x86 specifics.

Needless to say, code should use the generic functions - this file is *only*
here to *document* the inner workings of x86 topology.

Started by Thomas Gleixner <tglx@linutronix.de> and Borislav Petkov <bp@alien8.de>.

The main aim of the topology facilities is to present adequate interfaces to
code which needs to know/query/use the structure of the running system wrt
threads, cores, packages, etc.

The kernel does not care about the concept of physical sockets because a
socket has no relevance to software. It's an electromechanical component. In
the past a socket always contained a single package (see below), but with the
advent of Multi Chip Modules (MCM) a socket can hold more than one package. So
there might be still references to sockets in the code, but they are of
historical nature and should be cleaned up.

The topology of a system is described in the units of:

    - packages
    - cores
    - threads

* Package:

  Packages contain a number of cores plus shared resources, e.g. DRAM
  controller, shared caches etc.

  AMD nomenclature for package is 'Node'.

  Package-related topology information in the kernel:

  - cpuinfo_x86.x86_max_cores:

    The number of cores in a package. This information is retrieved via CPUID.

  - cpuinfo_x86.phys_proc_id:

    The physical ID of the package. This information is retrieved via CPUID
    and deduced from the APIC IDs of the cores in the package.

  - cpuinfo_x86.logical_id:

    The logical ID of the package. As we do not trust BIOSes to enumerate the
    packages in a consistent way, we introduced the concept of logical package
    ID so we can sanely calculate the number of maximum possible packages in
    the system and have the packages enumerated linearly.

  - topology_max_packages():

    The maximum possible number of packages in the system. Helpful for per
    package facilities to preallocate per package information.


* Cores:

  A core consists of 1 or more threads. It does not matter whether the threads
  are SMT- or CMT-type threads.

  AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses
  "core".

  Core-related topology information in the kernel:

  - smp_num_siblings:

    The number of threads in a core. The number of threads in a package can be
    calculated by:

	threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings


* Threads:

  A thread is a single scheduling unit. It's the equivalent to a logical Linux
  CPU.

  AMDs nomenclature for CMT threads is "Compute Unit Core". The kernel always
  uses "thread".

  Thread-related topology information in the kernel:

  - topology_core_cpumask():

    The cpumask contains all online threads in the package to which a thread
    belongs.

    The number of online threads is also printed in /proc/cpuinfo "siblings."

  - topology_sibling_mask():

    The cpumask contains all online threads in the core to which a thread
    belongs.

   - topology_logical_package_id():

    The logical package ID to which a thread belongs.

   - topology_physical_package_id():

    The physical package ID to which a thread belongs.

   - topology_core_id();

    The ID of the core to which a thread belongs. It is also printed in /proc/cpuinfo
    "core_id."



System topology examples

Note:

The alternative Linux CPU enumeration depends on how the BIOS enumerates the
threads. Many BIOSes enumerate all threads 0 first and then all threads 1.
That has the "advantage" that the logical Linux CPU numbers of threads 0 stay
the same whether threads are enabled or not. That's merely an implementation
detail and has no practical impact.

1) Single Package, Single Core

   [package 0] -> [core 0] -> [thread 0] -> Linux CPU 0

2) Single Package, Dual Core

   a) One thread per core

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
		    -> [core 1] -> [thread 0] -> Linux CPU 1

   b) Two threads per core

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
				-> [thread 1] -> Linux CPU 1
		    -> [core 1] -> [thread 0] -> Linux CPU 2
				-> [thread 1] -> Linux CPU 3

      Alternative enumeration:

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
				-> [thread 1] -> Linux CPU 2
		    -> [core 1] -> [thread 0] -> Linux CPU 1
				-> [thread 1] -> Linux CPU 3

      AMD nomenclature for CMT systems:

	[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
				     -> [Compute Unit Core 1] -> Linux CPU 1
		 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
				     -> [Compute Unit Core 1] -> Linux CPU 3

4) Dual Package, Dual Core

   a) One thread per core

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
		    -> [core 1] -> [thread 0] -> Linux CPU 1

	[package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
		    -> [core 1] -> [thread 0] -> Linux CPU 3

   b) Two threads per core

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
				-> [thread 1] -> Linux CPU 1
		    -> [core 1] -> [thread 0] -> Linux CPU 2
				-> [thread 1] -> Linux CPU 3

	[package 1] -> [core 0] -> [thread 0] -> Linux CPU 4
				-> [thread 1] -> Linux CPU 5
		    -> [core 1] -> [thread 0] -> Linux CPU 6
				-> [thread 1] -> Linux CPU 7

      Alternative enumeration:

	[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
				-> [thread 1] -> Linux CPU 4
		    -> [core 1] -> [thread 0] -> Linux CPU 1
				-> [thread 1] -> Linux CPU 5

	[package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
				-> [thread 1] -> Linux CPU 6
		    -> [core 1] -> [thread 0] -> Linux CPU 3
				-> [thread 1] -> Linux CPU 7

      AMD nomenclature for CMT systems:

	[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
				     -> [Compute Unit Core 1] -> Linux CPU 1
		 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
				     -> [Compute Unit Core 1] -> Linux CPU 3

	[node 1] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 4
				     -> [Compute Unit Core 1] -> Linux CPU 5
		 -> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 6
				     -> [Compute Unit Core 1] -> Linux CPU 7
+7 −4
Original line number Diff line number Diff line
@@ -5042,6 +5042,7 @@ F: include/linux/hw_random.h
HARDWARE SPINLOCK CORE
M:	Ohad Ben-Cohen <ohad@wizery.com>
M:	Bjorn Andersson <bjorn.andersson@linaro.org>
L:	linux-remoteproc@vger.kernel.org
S:	Maintained
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
F:	Documentation/hwspinlock.txt
@@ -6402,7 +6403,7 @@ KPROBES
M:	Ananth N Mavinakayanahalli <ananth@in.ibm.com>
M:	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
M:	"David S. Miller" <davem@davemloft.net>
M:	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
M:	Masami Hiramatsu <mhiramat@kernel.org>
S:	Maintained
F:	Documentation/kprobes.txt
F:	include/linux/kprobes.h
@@ -8253,7 +8254,7 @@ F: Documentation/filesystems/overlayfs.txt

ORANGEFS FILESYSTEM
M:	Mike Marshall <hubcap@omnibond.com>
L:	pvfs2-developers@beowulf-underground.org
L:	pvfs2-developers@beowulf-underground.org (subscribers-only)
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux.git
S:	Supported
F:	fs/orangefs/
@@ -9314,6 +9315,7 @@ F: include/linux/regmap.h
REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
M:	Ohad Ben-Cohen <ohad@wizery.com>
M:	Bjorn Andersson <bjorn.andersson@linaro.org>
L:	linux-remoteproc@vger.kernel.org
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
S:	Maintained
F:	drivers/remoteproc/
@@ -9323,6 +9325,7 @@ F: include/linux/remoteproc.h
REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
M:	Ohad Ben-Cohen <ohad@wizery.com>
M:	Bjorn Andersson <bjorn.andersson@linaro.org>
L:	linux-remoteproc@vger.kernel.org
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
S:	Maintained
F:	drivers/rpmsg/
@@ -11137,8 +11140,8 @@ F: include/uapi/linux/tipc*.h
F:	net/tipc/

TILE ARCHITECTURE
M:	Chris Metcalf <cmetcalf@ezchip.com>
W:	http://www.ezchip.com/scm/
M:	Chris Metcalf <cmetcalf@mellanox.com>
W:	http://www.mellanox.com/repository/solutions/tile-scm/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
S:	Supported
F:	arch/tile/
+1 −1
Original line number Diff line number Diff line
VERSION = 4
PATCHLEVEL = 6
SUBLEVEL = 0
EXTRAVERSION = -rc1
EXTRAVERSION = -rc2
NAME = Blurry Fish Butt

# *DOCUMENTATION*
Loading