docs: i2c: convert to ReST and add to driver-api bookset

[linux.git] / Documentation / i2c / instantiating-devices.rst

diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices.rst
similarity index 93%
rename from Documentation/i2c/instantiating-devices
rename to Documentation/i2c/instantiating-devices.rst
index 345e9ea8281a70ee23fb9e4573a371c057efa768..1238f1fa3382051874c33128f77a993890d5ac30 100644 (file)
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices.rst
@@ -1,3 +1,4 @@
+==============================
 How to instantiate I2C devices
 ==============================
 
@@ -17,9 +18,9 @@ which is known in advance. It is thus possible to pre-declare the I2C
 devices which live on this bus. This is done with an array of struct
 i2c_board_info which is registered by calling i2c_register_board_info().
 
-Example (from omap2 h4):
+Example (from omap2 h4)::
 
-static struct i2c_board_info h4_i2c_board_info[] __initdata = {
+  static struct i2c_board_info h4_i2c_board_info[] __initdata = {
        {
                I2C_BOARD_INFO("isp1301_omap", 0x2d),
                .irq            = OMAP_GPIO_IRQ(125),
@@ -32,15 +33,15 @@ static struct i2c_board_info h4_i2c_board_info[] __initdata = {
                I2C_BOARD_INFO("24c01", 0x57),
                .platform_data  = &m24c01,
        },
-};
+  };
 
-static void __init omap_h4_init(void)
-{
+  static void __init omap_h4_init(void)
+  {
        (...)
        i2c_register_board_info(1, h4_i2c_board_info,
                        ARRAY_SIZE(h4_i2c_board_info));
        (...)
-}
+  }
 
 The above code declares 3 devices on I2C bus 1, including their respective
 addresses and custom data needed by their drivers. When the I2C bus in
@@ -57,7 +58,7 @@ Method 1b: Declare the I2C devices via devicetree
 This method has the same implications as method 1a. The declaration of I2C
 devices is here done via devicetree as subnodes of the master controller.
 
-Example:
+Example::
 
        i2c1: i2c@400a0000 {
                /* ... master properties skipped ... */
@@ -99,20 +100,20 @@ bus in advance, so the method 1 described above can't be used. Instead,
 you can instantiate your I2C devices explicitly. This is done by filling
 a struct i2c_board_info and calling i2c_new_device().
 
-Example (from the sfe4001 network driver):
+Example (from the sfe4001 network driver)::
 
-static struct i2c_board_info sfe4001_hwmon_info = {
+  static struct i2c_board_info sfe4001_hwmon_info = {
        I2C_BOARD_INFO("max6647", 0x4e),
-};
+  };
 
-int sfe4001_init(struct efx_nic *efx)
-{
+  int sfe4001_init(struct efx_nic *efx)
+  {
        (...)
        efx->board_info.hwmon_client =
                i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);
 
        (...)
-}
+  }
 
 The above code instantiates 1 I2C device on the I2C bus which is on the
 network adapter in question.
@@ -124,12 +125,12 @@ it may have different addresses from one board to the next (manufacturer
 changing its design without notice). In this case, you can call
 i2c_new_probed_device() instead of i2c_new_device().
 
-Example (from the nxp OHCI driver):
+Example (from the nxp OHCI driver)::
 
-static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
+  static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
 
-static int usb_hcd_nxp_probe(struct platform_device *pdev)
-{
+  static int usb_hcd_nxp_probe(struct platform_device *pdev)
+  {
        (...)
        struct i2c_adapter *i2c_adap;
        struct i2c_board_info i2c_info;
@@ -142,7 +143,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
                                                   normal_i2c, NULL);
        i2c_put_adapter(i2c_adap);
        (...)
-}
+  }
 
 The above code instantiates up to 1 I2C device on the I2C bus which is on
 the OHCI adapter in question. It first tries at address 0x2c, if nothing
@@ -172,6 +173,7 @@ explicitly. Instead, i2c-core will probe for such devices as soon as their
 drivers are loaded, and if any is found, an I2C device will be
 instantiated automatically. In order to prevent any misbehavior of this
 mechanism, the following restrictions apply:
+
 * The I2C device driver must implement the detect() method, which
   identifies a supported device by reading from arbitrary registers.
 * Only buses which are likely to have a supported device and agree to be
@@ -189,6 +191,7 @@ first.
 Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6
 kernels will find out that this method 3 is essentially similar to what
 was done there. Two significant differences are:
+
 * Probing is only one way to instantiate I2C devices now, while it was the
   only way back then. Where possible, methods 1 and 2 should be preferred.
   Method 3 should only be used when there is no other way, as it can have
@@ -224,11 +227,13 @@ device. As no two devices can live at the same address on a given I2C
 segment, the address is sufficient to uniquely identify the device to be
 deleted.
 
-Example:
-# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
+Example::
+
+  # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
 
 While this interface should only be used when in-kernel device declaration
 can't be done, there is a variety of cases where it can be helpful:
+
 * The I2C driver usually detects devices (method 3 above) but the bus
   segment your device lives on doesn't have the proper class bit set and
   thus detection doesn't trigger.