3 files changed, 77 insertions, 71 deletions

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml
index 9b35a422db..c3bda983b2 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -145,9 +145,9 @@
         </literallayout>
         The value of the entries in <filename>KERNEL_FEATURES</filename>
         are dependent on their location within the kernel Metadata itself.
-        The examples here are taken from the
-        <filename>linux-yocto-3.4</filename> repository where "features"
-        and "cfg" are subdirectories within the
+        The examples here are taken from the <filename>meta</filename>
+        branch of the <filename>linux-yocto-3.19</filename> repository.
+        Within that branch, "features" and "cfg" are subdirectories of the
         <filename>meta/cfg/kernel-cache</filename> directory.
         For more information, see the
         "<link linkend='kernel-metadata-syntax'>Kernel Metadata Syntax</link>" section.
@@ -442,22 +442,27 @@
             feature.
             This feature consists of one or more Linux kernel configuration
             parameters in a configuration fragment file
-            (<filename>.cfg</filename>) and an <filename>.scc</filename> file
+            (<filename>.cfg</filename>) and a <filename>.scc</filename> file
             that describes the fragment.
         </para>
 
         <para>
             The Symmetric Multi-Processing (SMP) fragment included in the
-            <filename>linux-yocto-3.4</filename> Git repository
+            <filename>linux-yocto-3.19</filename> Git repository
             consists of the following two files:
             <literallayout class='monospaced'>
      cfg/smp.scc:
         define KFEATURE_DESCRIPTION "Enable SMP"
+        define KFEATURE_COMPATIBILITY all
+
         kconf hardware smp.cfg
 
      cfg/smp.cfg:
         CONFIG_SMP=y
         CONFIG_SCHED_SMT=y
+        # Increase default NR_CPUS from 8 to 64 so that platform with
+        # more than 8 processors can be all activated at boot time
+        CONFIG_NR_CPUS=64
             </literallayout>
             You can find information on configuration fragment files in the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>Creating Configuration Fragments</ulink>"
@@ -584,7 +589,7 @@
         </para>
 
         <para>
-            As an example, the <filename>linux-yocto-3.4</filename>
+            As an example, the <filename>linux-yocto-3.19</filename>
             tree defines three kernel types: "standard",
             "tiny", and "preempt-rt":
             <itemizedlist>
@@ -671,15 +676,15 @@
             The hardware-specific portion is typically defined
             independently, and then aggregated with each supported kernel
             type.
-            Consider this simple BSP description that supports the "mybsp"
-            machine:
+            Consider this simple BSP description that supports the
+            <replaceable>mybsp</replaceable> machine:
             <literallayout class='monospaced'>
-     mybsp.scc:
-        define KMACHINE mybsp
+     <replaceable>mybsp</replaceable>.scc:
+        define KMACHINE <replaceable>mybsp</replaceable>
         define KTYPE standard
         define KARCH i386
 
-        kconf mybsp.cfg
+        kconf <replaceable>mybsp</replaceable>.cfg
             </literallayout>
             Every BSP description should define the
             <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
@@ -724,13 +729,13 @@
             a single <filename>.cfg</filename> file.
             Consider the following:
             <literallayout class='monospaced'>
-     mybsp.scc:
+     <replaceable>mybsp</replaceable>.scc:
         define KMACHINE mybsp
         define KTYPE standard
         define KARCH i386
 
         include standard.scc
-        include mybsp-hw.scc
+        include <replaceable>mybsp</replaceable>-hw.scc
             </literallayout>
         </para>
 
@@ -738,8 +743,10 @@
             In the above example, <filename>standard.scc</filename>
             aggregates all the configuration fragments, patches, and
             features that make up your standard kernel policy whereas
-            <filename>mybsp-hw.scc</filename> aggregates all those necessary
-            to support the hardware available on the "mybsp" machine.
+            <replaceable>mybsp</replaceable><filename>-hw.scc</filename>
+            aggregates all those necessary
+            to support the hardware available on the
+            <replaceable>mybsp</replaceable> machine.
             For information on how to break a complete
             <filename>.config</filename> file into the various
             configuration fragments, see the
@@ -751,99 +758,98 @@
             Many real-world examples are more complex.
             Like any other <filename>.scc</filename> file, BSP
             descriptions can aggregate features.
-            Consider the Fish River Island 2 (fri2)
-            BSP definition from the <filename>linux-yocto-3.4</filename>
+            Consider the Minnow BSP definition from the
+            <filename>linux-yocto-3.19</filename>
             Git repository:
             <literallayout class='monospaced'>
-     fri2.scc:
-        kconf hardware fri2.cfg
-
+     minnow.scc:
         include cfg/x86.scc
         include features/eg20t/eg20t.scc
         include cfg/dmaengine.scc
-        include features/ericsson-3g/f5521gw.scc
         include features/power/intel.scc
         include cfg/efi.scc
         include features/usb/ehci-hcd.scc
         include features/usb/ohci-hcd.scc
-        include features/iwlwifi/iwlwifi.scc
+        include features/usb/usb-gadgets.scc
+        include features/usb/touchscreen-composite.scc
+        include cfg/timer/hpet.scc
+        include cfg/timer/rtc.scc
+        include features/leds/leds.scc
+        include features/spi/spidev.scc
+        include features/i2c/i2cdev.scc
+
+        # Earlyprintk and port debug requires 8250
+        kconf hardware cfg/8250.cfg
+
+        kconf hardware minnow.cfg
+        kconf hardware minnow-dev.cfg
             </literallayout>
         </para>
 
         <para>
-            The <filename>fri2.scc</filename> description file includes
+            The <filename>minnow.scc</filename> description file includes
             a hardware configuration fragment
-            (<filename>fri2.cfg</filename>) specific to the Fish River
-            Island 2 BSP as well as several more general configuration
+            (<filename>minnow.cfg</filename>) specific to the Minnow
+            BSP as well as several more general configuration
             fragments and features enabling hardware found on the
             machine.
             This description file is then included in each of the three
-            "fri2" description files for the supported kernel types
+            "minnow" description files for the supported kernel types
             (i.e. "standard", "preempt-rt", and "tiny").
-            Consider the "fri2" description for the "standard" kernel
+            Consider the "minnow" description for the "standard" kernel
             type:
             <literallayout class='monospaced'>
-     fri2-standard.scc:
-        define KMACHINE fri2
+     minnow-standard.scc:
+        define KMACHINE minnow
         define KTYPE standard
         define KARCH i386
 
-        include ktypes/standard/standard.scc
-        branch fri2
-
-        git merge emgd-1.14
+        include ktypes/standard
 
-        include fri2.scc
+        include minnow.scc
 
-        # Extra fri2 configs above the minimal defined in fri2.scc
+        # Extra minnow configs above the minimal defined in minnow.scc
         include cfg/efi-ext.scc
-        include features/drm-emgd/drm-emgd.scc
-        include cfg/vesafb.scc
+        include features/media/media-all.scc
+        include features/sound/snd_hda_intel.scc
 
-        # default policy for standard kernels
+        # The following should really be in standard.scc
+        # USB live-image support
         include cfg/usb-mass-storage.scc
+        include cfg/boot-live.scc
+
+        # Basic profiling
+        include features/latencytop/latencytop.scc
+        include features/profiling/profiling.scc
+
+        # Requested drivers that don't have an existing scc
+        kconf hardware minnow-drivers-extra.cfg
             </literallayout>
             The <filename>include</filename> command midway through the file
-            includes the <filename>fri2.scc</filename> description that
+            includes the <filename>minnow.scc</filename> description that
             defines all hardware enablements for the BSP that is common to all
             kernel types.
             Using this command significantly reduces duplication.
         </para>
 
         <para>
-            This "fri2" standard description introduces a few more variables
-            and commands that are worth further discussion.
-            Notice the <filename>branch fri2</filename> command, which creates
-            a machine-specific branch into which source changes are applied.
-            With this branch set up, the <filename>git merge</filename> command
-            uses Git to merge in a feature branch named "emgd-1.14".
-            You could also handle this with the <filename>patch</filename>
-            command.
-            However, for commonly used features such as this, feature branches
-            are a convenient mechanism.
-            See the "<link linkend='feature-branches'>Feature Branches</link>"
-            section for more information.
-        </para>
-
-        <para>
-            Now consider the "fri2" description for the "tiny" kernel type:
+            Now consider the "minnow" description for the "tiny" kernel type:
             <literallayout class='monospaced'>
-     fri2-tiny.scc:
-        define KMACHINE fri2
+     minnow-tiny.scc:
+        define KMACHINE minnow
         define KTYPE tiny
         define KARCH i386
 
-        include ktypes/tiny/tiny.scc
-        branch fri2
+        include ktypes/tiny
 
-        include fri2.scc
+        include minnow.scc
             </literallayout>
             As you might expect, the "tiny" description includes quite a
             bit less.
             In fact, it includes only the minimal policy defined by the
             "tiny" kernel type and the hardware-specific configuration required
             for booting the machine along with the most basic functionality of
-            the system as defined in the base "fri2" description file.
+            the system as defined in the base "minnow" description file.
         </para>
 
         <para>
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 87cf2b3864..90a4f3876f 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -84,11 +84,11 @@
                 You also name it accordingly based on the linux-yocto recipe
                 you are using.
                 For example, if you are modifying the
-                <filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename>
+                <filename>meta/recipes-kernel/linux/linux-yocto_3.19.bb</filename>
                 recipe, the append file will typically be located as follows
                 within your custom layer:
                 <literallayout class='monospaced'>
-     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.4.bbappend
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.19.bbappend
                 </literallayout>
                 The append file should initially extend the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
@@ -578,7 +578,7 @@
                             </para></listitem>
                         <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>:
                             The Linux kernel version you are using (e.g.
-                            "3.4").</para></listitem>
+                            "3.19").</para></listitem>
                         <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'><filename>LINUX_VERSION_EXTENSION</filename></ulink>:
                             The Linux kernel <filename>CONFIG_LOCALVERSION</filename>
                             that is compiled into the resulting kernel and visible
@@ -604,7 +604,7 @@
                             The combined results are a string with
                             the following form:
                             <literallayout class='monospaced'>
-     3.4.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+     3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
                             </literallayout>
                             While lengthy, the extra verbosity in <filename>PV</filename>
                             helps ensure you are using the exact
@@ -844,7 +844,7 @@
             <para>
                 Here is an example that looks at what has changed in the
                 <filename>emenlow</filename> branch of the
-                <filename>linux-yocto-3.4</filename> kernel.
+                <filename>linux-yocto-3.19</filename> kernel.
                 The lower commit range is the commit associated with the
                 <filename>standard/base</filename> branch, while
                 the upper commit range is the commit associated with the
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.xml b/documentation/kernel-dev/kernel-dev-maint-appx.xml
index a72dcff01b..6bb0cf6fd0 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.xml
@@ -30,9 +30,9 @@
             in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
             Git tree.
             For example, the following command clones the Yocto Project baseline kernel that
-            branched off of <filename>linux.org</filename> version 3.4:
+            branched off of <filename>linux.org</filename> version 3.19:
             <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/linux-yocto-3.4
+     $ git clone git://git.yoctoproject.org/linux-yocto-3.19
             </literallayout>
             For another example of how to set up a local Git repository of the Yocto Project
             kernel files, see the
@@ -43,9 +43,9 @@
             Once you have cloned the kernel Git repository on your local machine, you can
             switch to the <filename>meta</filename> branch within the repository.
             Here is an example that assumes the local Git repository for the kernel is in
-            a top-level directory named <filename>linux-yocto-3.4</filename>:
+            a top-level directory named <filename>linux-yocto-3.19</filename>:
             <literallayout class='monospaced'>
-     $ cd linux-yocto-3.4
+     $ cd linux-yocto-3.19
      $ git checkout -b meta origin/meta
             </literallayout>
             Once you have checked out and switched to the <filename>meta</filename> branch,
@@ -135,7 +135,7 @@
 
 <!--
         <para>
-            <emphasis>AR - Darrren Hart:</emphasis>  Some parts of this section
+            <emphasis>AR - Darren Hart:</emphasis>  Some parts of this section
             need to be in the
             "<link linkend='using-an-iterative-development-process'>Using an Iterative Development Process</link>"
             section.