[FE training-materials-updates] Remove obsolete todo lists

[Michael Opdenacker]

Repository : git://git.free-electrons.com/training-materials.git

On branch  : master
Link       : http://git.free-electrons.com/training-materials/commit/?id=43339450f4d7ea38b2b3ad864c6458eb41b97d67

>---------------------------------------------------------------

commit 43339450f4d7ea38b2b3ad864c6458eb41b97d67
Author: Michael Opdenacker <michael.opdenacker at free-electrons.com>
Date:   Mon Mar 17 05:07:22 2014 +0100

    Remove obsolete todo lists
    
    - Were only used during the latest major update to our kernel course
    
    Signed-off-by: Michael Opdenacker <michael.opdenacker at free-electrons.com>


>---------------------------------------------------------------

43339450f4d7ea38b2b3ad864c6458eb41b97d67
 kernel-labs-todo.txt   |  116 ------------------------------------------------
 kernel-slides-todo.txt |    3 --
 2 files changed, 119 deletions(-)

diff --git a/kernel-labs-todo.txt b/kernel-labs-todo.txt
deleted file mode 100644
index fc1bac0..0000000
--- a/kernel-labs-todo.txt
+++ /dev/null
@@ -1,116 +0,0 @@
-Lab - Kernel sources
-
- * No longer use full tarballs + patches, directly use git clone +
-   create a branch.
-
- * However, git clone is long, shouldn't we make this lab just do the
-   git clone, and do the exploration of the sources together with the
-   compilation lab? Or we should give the training participants a
-   pre-cloned tree.
-
-Lab - Kernel configuration, cross-compiling and booting on NFS
-
- * Should be adapted to the BeagleBoneBlack. The main change is the
-   usage of the DTB. Note: the bootloader on the BBB must be updated
-   to be able to store the environment in MMC. Talk with Maxime about
-   this. Also make sure to use the patch that adds the DTB for the BBB
-   itself: using the BB DTB on BBB can burn your BBB.
-
-Lab - Writing modules
-
- * Not much differences here with the existing lab. Ultimately I think
-   we should remove the thing about the kernel version, but that can
-   be left for another time.
-
-   The part about creating the patch should either be removed, or put
-   in a "Going further section" that gives the steps to do this with
-   Git.
-
-Lab - Linux device model for an I2C driver
-
- * In this lab, we just add the description of the I2C device in the
-   Device Tree, and create a minimal driver that registers itself in
-   the I2C subsystem. We just verify that the ->probe() function gets
-   called when the module is inserted, and the ->remove() function
-   when the module is removed.
-
-   The module code is in
-   training/resources/solutions/input/nunchuk.c. The Device Tree
-   patches are in
-   training/resources/solutions/omap-serial/0003-arm-beaglebone-add-I2C1-bus.patch
-   and
-   git/training/resources/solutions/omap-serial/0004-arm-beaglebone-add-Nunchuk-device-on-I2C1.patch. Do
-   *not* add the pinmuxing for now, it is done in another lab.
-
-Lab - Communicate with the Nunchuk over I2C
-
- * In this lab, we add the pinmuxing to make the I2C bus really work,
-   and then we add a little bit of code to read the I2C registers of
-   the Nunchuk to check the button status. So maybe something like in
-   ->probe(), dump the value of the register. So the participant can
-   load the module, see the value of the register to find out that the
-   button is released. Then, unload the module, and reload it while
-   the button is pushed, and see the value modified.
-
-   Add a reference of the Nunchuk register layout.
-
-Lab - Expose the Nunchuk functionality to userspace
-
- * Now we bring the 'input' subsystem stuff into the mix (see the
-   existing nunchuk.c). We only report the events related to the
-   buttons C and Z. As a "going further" step, we could add the
-   joystick events.
-
- (this is the last lab on the nunchuk, the next labs are going to use
- the UART)
-
-Lab - Minimal platform driver and access to I/O memory
-
- * Modify the Device Tree to add an UART description, add the
-   pinmuxing entries, a minimal driver with a ->probe(), that does an
-   ioremap() and output one character on the UART.
-
-   Note: we can remove all the complexity of SSH + netconsole, since
-   we're using the second UART.
-
-   Note: some basic code is in
-   training/resources/solutions/omap-serial/omap-serial.c. The Device
-   Tree files to use UART3 and UART5 are in the
-   0005-arm-beaglebone-add-UART3-device-with-feserial-driver.patch and
-   0006-arm-beaglebone-add-UART5-device-with-feserial-driver.patch
-   patches. For now, only use two UARTs (the one for the debug, plus
-   the one we write the driver for). We will add a third UART later
-   on.
-
-Lab - Output-only serial port driver
-
- * A bit like our previous character driver lab, but uses the misc
-   subsystem.
-
-   Add the third UART, so that the participant can see his ->probe()
-   function called twice and use two different UARTs with his driver.
-
-Lab - Sleeping and handling interrupts in a device driver
-
- * Very similar to the lab we already have, just adapted to OMAP. See
-   the code in omap-serial.c to see how to set up interrupts and so
-   on.
-
-Lab - Locking
-
- * Same lab as today, just ported to the BBB.
-
-   It would be good to improve it to really expose a locking
-   problem. Here is an idea: in the transmit function, we do a loop to
-   wait for the transmit FIFO to be empty, and then we send the
-   character. We introduce a delay between the two things, with
-   mdelay() or something like this. Then, from userspace, two
-   applications are running, one write ABCDEFGHIJK continuously, the
-   other one 0123456789 continuously. We should see some bytes "eaten"
-   because there is no synchronization on the transmit side. Adding a
-   spinlock should exhibit that all the characters are properly seen.
-
-Lab - Investigating kernel faults
-
- * Same lab as today, just ported to the BBB.
-
diff --git a/kernel-slides-todo.txt b/kernel-slides-todo.txt
deleted file mode 100644
index 5a792f1..0000000
--- a/kernel-slides-todo.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-- Git sources
-  - Properly introduce the Linux stable tree
-