[FE training-materials-updates] kernel: Add some i2c1 pin muxing testing

[Maxime Ripard]

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

On branch  : kernel-ng
Link       : http://git.free-electrons.com/training-materials/commit/?id=63c21b3309898e6c7af3317663459cad970de8fd

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

commit 63c21b3309898e6c7af3317663459cad970de8fd
Author: Maxime Ripard <maxime.ripard at free-electrons.com>
Date:   Thu Oct 3 16:20:00 2013 +0200

    kernel: Add some i2c1 pin muxing testing
    
    i2cdetect -F never actually use the bus, but only probe the driver to
    know what it's capable of handling. Add an i2cdetect -r run to actually
    scan the bus and make sure the muxing is right.
    
    Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>


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

63c21b3309898e6c7af3317663459cad970de8fd
 .../kernel-i2c-communication.tex                   |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/labs/kernel-i2c-communication/kernel-i2c-communication.tex b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
index 17506f1..45293b7 100644
--- a/labs/kernel-i2c-communication/kernel-i2c-communication.tex
+++ b/labs/kernel-i2c-communication/kernel-i2c-communication.tex
@@ -68,6 +68,15 @@ I2C Block Write                  yes
 I2C Block Read                   yes
 \end{verbatim}
 
+You can see that the {\em SMBus Quick Commands} are not available on
+this driver, yet \code{i2cdetect} uses them by default to scan the i2c
+bus. You can use \code{i2cdetect -r} to use the usual set of i2c
+commands, and by able to detect the devices on your bus.
+
+To test if everything works fine, run \code{i2cdetect -r 1}. This will
+scan the \code{i2c1} bus for devices. You should see a device at the
+address \code{0x52}. This is your nunchuk.
+
 If everything works as expected, commit your Device Tree changes. This
 will be required switch to another branch later: