4412 Try to transplant mpu9250

The IO of the 4412 board is all 1.8v. Only I2C6 is converted to 3.3v. So I plan to use I2C6 to drive mpu9250

1. First remove the occupied modules

Remove the touch driver in menuconfig

• Device Drivers --->

• Input device support --->

• Touchscreens --->

• FT5X0X based touchscreens (remove)

Then remove the RC522 driver (SPI occupies I2C)

• Device Drivers --->

• SPI support --->

• < > RC522 Module driver support (remove)

-> Networking support (NET [=y])                                 
-> CAN bus subsystem support (CAN [=y])                        
 -> CAN Device Drivers                                          
-> Platform CAN drivers with Netlink support (CAN_DEV [=y])

    < > Microchip MCP251x SPI CAN controllers

2. Add devices in mach-itop4412.c

static struct i2c_board_info i2c_devs6[] __initdata = {
    {
        I2C_BOARD_INFO("mpu9250", MPU9250_ADDRESS),
    },
};

Here, MPU9250_ADDRESS should be 7 bits. If you write 0XD0, it means MPU9250_ADDRESS>>1

Then after the kernel is compiled, burn it into the development board

cat /sys/bus/i2c/devices, there will be 6-0068, this file

Wrote an empty I2C template:

 i2c_9250.c

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#define I2C6_9250_NAME "mpu9250"

#define I2C_SDA6 EXYNOS4_GPC1(3)

#define I2C_SCL6 EXYNOS4_GPC1(4)

static int i2c_mpu9250_probe(struct i2c_client *client, const struct i2c_device_id *id)

{

    printk("==%s: n", __FUNCTION__);

    return 0;

}

static int __devexit i2c_mpu9250_remove(struct i2c_client *client)

{

    i2c_set_clientdata(client, NULL); //Set client to NULL

    printk("==%s: n", __FUNCTION__);

    return 0;

}

static const struct i2c_device_id i2c_mpu9250_id[] = {

    { I2C6_9250_NAME, 0 },

    { }

};

static struct i2c_driver i2c_mpu9250_driver = {

    .probe = i2c_mpu9250_probe,

    .remove = __devexit_p(i2c_mpu9250_remove),

    .id_table = i2c_mpu9250_id,

    .driver = {

        .name = I2C6_9250_NAME,

        .owner = THIS_MODULE,

    },

};

static void i2c_io_init()

{

    int ret;

    ret = gpio_request(I2C_SCL6, "I2C_SCL6");

    if(ret) {

        printk(KERN_ERR "failed to request TP1_EN for I2C controln");

    }

    gpio_direction_output(I2C_SCL6, 1);

    s3c_gpio_cfgpin(I2C_SCL6, S3C_GPIO_OUTPUT);

    gpio_free(I2C_SCL6);

    mdelay(5);

    ret = gpio_request(I2C_SDA6, "I2C_SDA6");

    if(ret) {

        gpio_free(I2C_SDA6);

        ret = gpio_request(I2C_SDA6, "I2C_SDA6");

        if(ret) {

            printk("i2c_io_test: Fialed to request I2C_SDA6 n");

        }

    }

    gpio_direction_output(I2C_SDA6, 0);

    mdelay(200);

    gpio_direction_output(I2C_SDA6, 1);

    s3c_gpio_cfgpin(I2C_SDA6, S3C_GPIO_OUTPUT);

    gpio_free(I2C_SDA6);

    msleep(300);

    printk("==%s: n", __FUNCTION__);

}

static int __init i2c_mpu9250_init(void)

{

    printk("==%s: n", __FUNCTION__);

    i2c_io_init();

    return i2c_add_driver(&i2c_mpu9250_driver);

}

static void __exit i2c_mpu9250_exit(void)

{

    printk("==%s: n", __FUNCTION__);

    i2c_del_driver(&i2c_mpu9250_driver);

}

late_initcall(i2c_mpu9250_init); //delayed loading

module_exit(i2c_mpu9250_exit);

MODULE_LICENSE("GPL");

MODULE_DESCRIPTION("mpu9250");

MODULE_AUTHOR("ChenTuo");

3. I2C architecture hierarchy classification 　

• The first layer: provides the hardware driver of the i2c adapter, detects and initializes the i2c adapter (such as applying for the i2c io address and interrupt number), drives the i2c adapter controlled by the soc to generate signals (start, stop, ack) on the hardware and handles the i2c interrupt. The hardware implementation layer in the overlay diagram 　

• The second layer: provides the algorithm of the i2c adapter, uses the xxx_xferf() function of the specific adapter to fill the master_xfer function pointer of i2c_algorithm, and assigns the assigned i2c_algorithm to the algo pointer of i2c_adapter. The access abstraction layer and i2c core layer in the overlay diagram 　

• The third layer: implements the i2c_driver interface in the i2c device driver, and uses the specific i2c device's attach_adapter() and detach_adapter() methods to assign values ​​to the member function pointers of i2c_driver. This implements the connection between the device and the bus (or adapter). The driver layer in the overlay diagram 　

• The fourth layer: implement the driver of the specific device corresponding to the i2c device. The i2c_driver only realizes the connection between the device and the bus, and the devices connected to the bus are very different, so it is necessary to implement the write(), read(), ioctl() and other methods of the specific device, assign them to file_operations, and then register character devices (mostly character devices). Overlay the driver layer in the figure.

• --------------------- This article comes from zqixiao_09's CSDN blog. For the full text, please click: https://blog.csdn.net/zqixiao_09/article/details/50916916?utm_source=copy

4. Detailed analysis of the three parts of the I2C driver architecture under Linux

4.1 IIC Core

　　The IIC core provides the registration and deregistration methods for the IIC bus driver and the device driver. In the I2C folder of the Linux driver, there are three folders: alogs, busses, and chips, and two files: i2c-core.c and i2c-dev.c.

4.2 IIC bus driver

　　The IIC bus driver is for IIC hardware. The adapter can be controlled by the CPU, and the IIC is directly integrated into the CPU. The IIC driver includes the IIC adapter data structure i2c_adapter, the IIC adapter algorithm data structure i2c-algorithm, and the controller's function of generating communication signals. i2c_xfer in i2c_algorithm is the low-level read and write implementation of i2c.

4.3 IIC Device Driver

　　The IIC device driver mainly includes the data structures i2c_driver and i2c_client, and we need to implement the member functions according to the specific device.

The I2Cdriver is implemented in the i2c-dev.c file, including interface functions for standard file operations such as open, release, read, write, and ioctl.

Any I2C device can be accessed through the common methods provided by I2Cdriver.

5. Some related data structures

i2c_msg:

struct i2c_msg

struct i2c_msg {

    __u16 addr; /* slave address */

    __u16 flags;

#define I2C_M_TEN 0x0010 /* this is a ten bit chip address */

#define I2C_M_RD 0x0001 /* read data, from slave to master */

#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_PROTOCOL_MANGLING */

#define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */

#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */

#define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */

#define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */

    __u16 len; /* msg length */

    __u8 *buf; /* pointer to msg data */

};

I2C_M_TEN: I2C is 8 bits by default. If the flags of i2c_msg are not configured with I2C_M_TEN,

I2C_M_RD: Indicates that this is a read operation

I2C_M_NOSTART: No start bit

I2C_M_REV_DIR_ADDR: read and write flag bit inversion

I2C_M_IGNORE_NAK: Ignore ACK and NACK

I2C_M_NO_RD_ACK: ignore ACK when reading