tune: README: Whitespace cleanup

Before making content changes, cleanup the various whitespace errors in
this file. Mostly end-of-line whitepsace.

(From OE-Core rev: 112e291c14ce4c3b8d074b71e63500dce609784e)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@intel.com>
Cc: Tom Zanussi <tom.zanussi@intel.com>
Cc: Nitin Kamble <nitin.a.kamble@intel.com>
Cc: Mark Hatle <mark.hatle@windriver.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 44 insertions, 44 deletions

diff --git a/meta/conf/machine/include/README b/meta/conf/machine/include/README
index e4b59c9..65d0942 100644
--- a/meta/conf/machine/include/README
+++ b/meta/conf/machine/include/README
@@ -1,27 +1,27 @@
 2012/03/30 - Mark Hatle <mark.hatle@windriver.com>
  - Initial Revision
 
-The individual CPU, and ABI tunings are contained in this directory.  A 
-number of local and global variables are used to control the way the 
-tunings are setup and how they work together to specify an optimized 
+The individual CPU, and ABI tunings are contained in this directory.  A
+number of local and global variables are used to control the way the
+tunings are setup and how they work together to specify an optimized
 configuration.
 
-The following is brief summary of the generic components that are used 
+The following is brief summary of the generic components that are used
 in these tunings.
 
-AVAILTUNES - This is a list of all of the tuning definitions currently 
-available in the system.  Not all tunes in this list may be compatible 
-with the machine configuration, or each other in a multilib 
-configuration.  Each tuning file can add to this list using "+=", but 
+AVAILTUNES - This is a list of all of the tuning definitions currently
+available in the system.  Not all tunes in this list may be compatible
+with the machine configuration, or each other in a multilib
+configuration.  Each tuning file can add to this list using "+=", but
 should never replace the list using "=".
 
-DEFAULTTUNE - This specifies the tune to use for a particular build.  
-Each tune should specify a reasonable default, which can be overriden by 
-a machine or multilib configuration.  The specified tune must be listed 
+DEFAULTTUNE - This specifies the tune to use for a particular build.
+Each tune should specify a reasonable default, which can be overriden by
+a machine or multilib configuration.  The specified tune must be listed
 in the AVAILTUNES.
 
-TUNEVALID[feature] - The <feature> is defined with a human readable 
-explanation for what it does.  All architectural, cpu, abi, etc tuning 
+TUNEVALID[feature] - The <feature> is defined with a human readable
+explanation for what it does.  All architectural, cpu, abi, etc tuning
 features must be defined using TUNEVALID.
 
 TUNECONFLICTS[feature] - A list of features which conflict with <feature>.
@@ -31,51 +31,51 @@ tuning ends up with features which conflict with each other.
 TUNE_FEATURES - This is automatically defined as TUNE_FEATURES_tune-<tune>.
 See TUNE_FEATURES_tune-<tune> for more information.
 
-TUNE_FEATURES_tune-<tune> - Specify the features used to describe a 
-specific tune.  This is a list of features that a tune support, each 
-feature must be in the TUNEVALID list.  Note: the tune and a given 
-feature name may be the same, but they have different purposes.  Only 
-features may be used to change behavior, while tunes are used to 
+TUNE_FEATURES_tune-<tune> - Specify the features used to describe a
+specific tune.  This is a list of features that a tune support, each
+feature must be in the TUNEVALID list.  Note: the tune and a given
+feature name may be the same, but they have different purposes.  Only
+features may be used to change behavior, while tunes are used to
 describe an overall set of features.
 
-ABIEXTENSION - An ABI extension may be specified by a specific feature 
-or other tuning setting, such as TARGET_FPU.  Any ABI extensions either 
-need to be defined in the architectures base arch file, i.e.  
-ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune 
+ABIEXTENSION - An ABI extension may be specified by a specific feature
+or other tuning setting, such as TARGET_FPU.  Any ABI extensions either
+need to be defined in the architectures base arch file, i.e.
+ABIEXTENSION = "eabi" in the arm case, or appended to in specific tune
 files with a ".=".  Spaces are not allowed in this variable.
 
-TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.  
-These should be additive when defined using "+=".  All items in this 
-list should be dynamic! i.e. 
+TUNE_CCARGS - Setup the cflags based on the TUNE_FEATURES settings.
+These should be additive when defined using "+=".  All items in this
+list should be dynamic! i.e.
 ${@bb.utils.contains("TUNE_FEATURES", "feature", "cflag", "!cflag", d)}
 
-TUNE_ARCH - The GNU canonical arch for a specific architecture.  i.e. 
-arm, armeb, mips, mips64, etc.  This value is by bitbake to setup 
-configure. TUNE_ARCH definitions are specific to a given architecture.  
-They may be a single static definitions, or may be dynamically adjusted.  
+TUNE_ARCH - The GNU canonical arch for a specific architecture.  i.e.
+arm, armeb, mips, mips64, etc.  This value is by bitbake to setup
+configure. TUNE_ARCH definitions are specific to a given architecture.
+They may be a single static definitions, or may be dynamically adjusted.
 See each architectures README for details for that CPU family.
 
-TUNE_PKGARCH - The package architecture used by the packaging systems to 
-define the architecture, abi and tuning of a particular package.  
-Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to 
-each architecture. See each architectures README for details for that 
+TUNE_PKGARCH - The package architecture used by the packaging systems to
+define the architecture, abi and tuning of a particular package.
+Similarly to TUNE_ARCH, the definition of TUNE_PKGARCH is specific to
+each architecture. See each architectures README for details for that
 CPU family.
 
-PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package 
-architectures.  By default this is equal to 
-PACKAGE_EXTRA_ARCHS_tune-<tune>.  If an architecture deviates from the 
+PACKAGE_EXTRA_ARCHS - Lists all runtime compatible package
+architectures.  By default this is equal to
+PACKAGE_EXTRA_ARCHS_tune-<tune>.  If an architecture deviates from the
 default it will be listed in the architecture README.
 
-PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures 
-that are compatible with this specific tune.  The package arch of this 
+PACKAGE_EXTRA_ARCHS_tune-<tune> - List all of the package architectures
+that are compatible with this specific tune.  The package arch of this
 tune must be in the list.
 
-TARGET_FPU - The FPU setting for a given tune, hard (generate floating 
-point instructions), soft (generate internal gcc calls), "other" 
-architecture specific floating point.  This is synchronized with the 
-compiler and other toolchain items.  This should be dynamically 
+TARGET_FPU - The FPU setting for a given tune, hard (generate floating
+point instructions), soft (generate internal gcc calls), "other"
+architecture specific floating point.  This is synchronized with the
+compiler and other toolchain items.  This should be dynamically
 configured in the same way that TUNE_CCARGS is.
 
-BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI.  This is 
-used in a multilib configuration to place the libraries in the correct, 
+BASE_LIB_tune-<tune> - The "/lib" location for a specific ABI.  This is
+used in a multilib configuration to place the libraries in the correct,
 non-conflicting locations.