Merge remote-tracking branch 'remotes/pmaydell/tags/pull-docs-20200312' into staging

docs queue:
 * Remove some no longer needed texinfo infrastructure
 * Reorder the top level index docs to put most useful manuals first
 * Split the Arm target-specific info into sub-pages
 * Improve the Arm documentation a bit with info previously
   only on the wiki page

# gpg: Signature made Thu 12 Mar 2020 11:42:10 GMT
# gpg:                using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg:                issuer "peter.maydell@linaro.org"
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@gmail.com>" [ultimate]
# gpg:                 aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-docs-20200312:
  docs: Be consistent about capitalization of 'Arm'
  docs: Move arm-cpu-features.rst into the system manual
  docs/system/target-arm.rst: Add some introductory text
  docs/system: Split target-arm.rst into sub-documents
  Makefile: Allow for subdirectories in Sphinx manual dependencies
  docs/qemu-option-trace.rst.inc: Remove redundant comment
  docs/index.rst, docs/index.html.in: Reorder manuals
  Makefile: Make all Sphinx documentation depend on the extensions
  docs/sphinx/hxtool.py: Remove STEXI/ETEXI support
  hxtool: Remove Texinfo generation support
  Update comments in .hx files that mention Texinfo
  Makefile: Remove redundant Texinfo related code

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

5 files changed, 8 insertions, 8 deletions

diff --git a/docs/devel/atomics.txt b/docs/devel/atomics.txt
index a4db3a4..67bdf82 100644
--- a/docs/devel/atomics.txt
+++ b/docs/devel/atomics.txt
@@ -87,7 +87,7 @@ Sequentially consistent loads and stores can be done using:
     atomic_xchg(ptr, val) for stores
 
 However, they are quite expensive on some platforms, notably POWER and
-ARM.  Therefore, qemu/atomic.h provides two primitives with slightly
+Arm.  Therefore, qemu/atomic.h provides two primitives with slightly
 weaker constraints:
 
     typeof(*ptr) atomic_mb_read(ptr)
diff --git a/docs/devel/kconfig.rst b/docs/devel/kconfig.rst
index b7bca44..e5df72b 100644
--- a/docs/devel/kconfig.rst
+++ b/docs/devel/kconfig.rst
@@ -8,7 +8,7 @@ time different targets can share large amounts of code.  For example,
 a POWER and an x86 board can run the same code to emulate a PCI network
 card, even though the boards use different PCI host bridges, and they
 can run the same code to emulate a SCSI disk while using different
-SCSI adapters.  ARM, s390 and x86 boards can all present a virtio-blk
+SCSI adapters.  Arm, s390 and x86 boards can all present a virtio-blk
 disk to their guests, but with three different virtio guest interfaces.
 
 Each QEMU target enables a subset of the boards, devices and buses that
diff --git a/docs/devel/loads-stores.rst b/docs/devel/loads-stores.rst
index 03aa9e7..0d99eb2 100644
--- a/docs/devel/loads-stores.rst
+++ b/docs/devel/loads-stores.rst
@@ -302,7 +302,7 @@ way QEMU defines the view of memory that a device or CPU has.
 or bus fabric.)
 
 Each CPU has an AddressSpace. Some kinds of CPU have more than
-one AddressSpace (for instance ARM guest CPUs have an AddressSpace
+one AddressSpace (for instance Arm guest CPUs have an AddressSpace
 for the Secure world and one for NonSecure if they implement TrustZone).
 Devices which can do DMA-type operations should generally have an
 AddressSpace. There is also a "system address space" which typically
diff --git a/docs/devel/multi-thread-tcg.txt b/docs/devel/multi-thread-tcg.txt
index 782bebc..3c85ac0 100644
--- a/docs/devel/multi-thread-tcg.txt
+++ b/docs/devel/multi-thread-tcg.txt
@@ -227,7 +227,7 @@ minimise contention.
 (Current solution)
 
 MMIO access automatically serialises hardware emulation by way of the
-BQL. Currently ARM targets serialise all ARM_CP_IO register accesses
+BQL. Currently Arm targets serialise all ARM_CP_IO register accesses
 and also defer the reset/startup of vCPUs to the vCPU context by way
 of async_run_on_cpu().
 
@@ -268,7 +268,7 @@ ordered backends this could become a NOP.
 Aside from explicit standalone memory barrier instructions there are
 also implicit memory ordering semantics which comes with each guest
 memory access instruction. For example all x86 load/stores come with
-fairly strong guarantees of sequential consistency where as ARM has
+fairly strong guarantees of sequential consistency whereas Arm has
 special variants of load/store instructions that imply acquire/release
 semantics.
 
@@ -317,7 +317,7 @@ x86 cmpxchg instruction.
 
 The second type offer a pair of load/store instructions which offer a
 guarantee that a region of memory has not been touched between the
-load and store instructions. An example of this is ARM's ldrex/strex
+load and store instructions. An example of this is Arm's ldrex/strex
 pair where the strex instruction will return a flag indicating a
 successful store only if no other CPU has accessed the memory region
 since the ldrex.
@@ -339,7 +339,7 @@ CURRENT OPEN QUESTIONS:
 
 The TCG provides a number of atomic helpers (tcg_gen_atomic_*) which
 can be used directly or combined to emulate other instructions like
-ARM's ldrex/strex instructions. While they are susceptible to the ABA
+Arm's ldrex/strex instructions. While they are susceptible to the ABA
 problem so far common guests have not implemented patterns where
 this may be a problem - typically presenting a locking ABI which
 assumes cmpxchg like semantics.
diff --git a/docs/devel/tcg.rst b/docs/devel/tcg.rst
index 4956a30..4ebde44 100644
--- a/docs/devel/tcg.rst
+++ b/docs/devel/tcg.rst
@@ -83,7 +83,7 @@ memory until the end of the translation block.  This is done for internal
 emulation state that is rarely accessed directly by the program and/or changes
 very often throughout the execution of a translation block---this includes
 condition codes on x86, delay slots on SPARC, conditional execution on
-ARM, and so on.  This state is stored for each target instruction, and
+Arm, and so on.  This state is stored for each target instruction, and
 looked up on exceptions.
 
 MMU emulation