平台，设备，驱动

继上次研究ADC驱动，开始接触platform这个东西。不过坦白讲，还是理解的不是很透彻。所以准备今天爬一次code。以加深这方面的理解。
我们来看一个led灯的驱动是如何用平台总线来实现的：

struct gpio_led {
    const char *name;
    const char *default_trigger;//触发方式
    unsigned    gpio;
    unsigned    active_low : 1;//是高电平点亮还是低电平点亮
    unsigned    retain_state_suspended : 1;//休眠时是否保存状态，等到唤醒后恢复
    unsigned    default_state : 2;//初始化的状态
    /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
};
struct gpio_led_platform_data {
    int         num_leds;//led的个数
    const struct gpio_led *leds;//led的结构数组

#define GPIO_LED_NO_BLINK_LOW   0   /* No blink GPIO state low */
#define GPIO_LED_NO_BLINK_HIGH  1   /* No blink GPIO state high */
#define GPIO_LED_BLINK      2   /* Please, blink */
    int     (*gpio_blink_set)(unsigned gpio, int state,
                    unsigned long *delay_on,
                    unsigned long *delay_off);/*闪烁的函数指针，这里就比较像c++ 类的思想了*/
};

构造一个平台设备，然后将设备挂载到platform的总线上。
驱动会遍历相同总线下的所有设备，找到和本身驱动列表中name相同的设备。如果有，则绑定驱动到具体的设备，如果无，则不做任何处理。
一般情况下，设备挂载成功会在sys/bus/platform/devices 目录下面找到你的设备
如果驱动挂载成功，会在sys/bus/platform/drivers目录下找到你的驱动文件
那platform是一种虚拟总线，下面挂着平台设备和平台驱动。

1.如何构造一个平台设备？

struct platform_device {
    const char  *name;//设备名称，没什么好讲的，一般这边的name要和对应的驱动或者驱动列表里面的name一致，否则驱动无法绑定成功
    int     id;//设备id，linux内核允许多个同名设备，同名设备间的区别用id来鉴别，PLATFORM_DEVID_NONE（-1）
PLATFORM_DEVID_AUTO（-2）
    bool        id_auto;// 初始化此flag,可以让内核自动分配id
    struct device     dev;//设备结构体，platform_device是由这个结构体抽象来的
    u32     num_resources;//资源数
    struct resource *resource;//资源列表，2者同时出现，用于描述资源，一般包括I/O、Memory、Register、IRQ、DMA、Bus等多种类型

    const struct platform_device_id *id_entry;//平台设备列表

    /* MFD cell pointer */
    struct mfd_cell *mfd_cell;

    /* arch specific additions */
    struct pdev_archdata    archdata;
};

我们粗略看完了platform_device 这个结构体。然后继续分析它里面的一些结构体：
device结构体

/**
 * struct device - The basic device structure
 * @parent: The device's "parent" device, the device to which it is attached.
 *      In most cases, a parent device is some sort of bus or host
 *      controller. If parent is NULL, the device, is a top-level device,
 *      which is not usually what you want.
 * @p:      Holds the private data of the driver core portions of the device.
 *      See the comment of the struct device_private for detail.
 * @kobj:   A top-level, abstract class from which other classes are derived.
 * @init_name:  Initial name of the device.
 * @type:   The type of device.
 *      This identifies the device type and carries type-specific
 *      information.
 * @mutex:  Mutex to synchronize calls to its driver.
 * @bus:    Type of bus device is on.
 * @driver: Which driver has allocated this
 * @platform_data: Platform data specific to the device.
 *      Example: For devices on custom boards, as typical of embedded
 *      and SOC based hardware, Linux often uses platform_data to point
 *      to board-specific structures describing devices and how they
 *      are wired.  That can include what ports are available, chip
 *      variants, which GPIO pins act in what additional roles, and so
 *      on.  This shrinks the "Board Support Packages" (BSPs) and
 *      minimizes board-specific #ifdefs in drivers.
 * @power:  For device power management.
 *      See Documentation/power/devices.txt for details.
 * @pm_domain:  Provide callbacks that are executed during system suspend,
 *      hibernation, system resume and during runtime PM transitions
 *      along with subsystem-level and driver-level callbacks.
 * @pins:   For device pin management.
 *      See Documentation/pinctrl.txt for details.
 * @numa_node:  NUMA node this device is close to.
 * @dma_mask:   Dma mask (if dma'ble device).
 * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
 *      hardware supports 64-bit addresses for consistent allocations
 *      such descriptors.
 * @dma_parms:  A low level driver may set these to teach IOMMU code about
 *      segment limitations.
 * @dma_pools:  Dma pools (if dma'ble device).
 * @dma_mem:    Internal for coherent mem override.
 * @archdata:   For arch-specific additions.
 * @of_node:    Associated device tree node.
 * @acpi_node:  Associated ACPI device node.
 * @devt:   For creating the sysfs "dev".
 * @id:     device instance
 * @devres_lock: Spinlock to protect the resource of the device.
 * @devres_head: The resources list of the device.
 * @knode_class: The node used to add the device to the class list.
 * @class:  The class of the device.
 * @groups: Optional attribute groups.
 * @release:    Callback to free the device after all references have
 *      gone away. This should be set by the allocator of the
 *      device (i.e. the bus driver that discovered the device).
 *
 * At the lowest level, every device in a Linux system is represented by an
 * instance of struct device. The device structure contains the information
 * that the device model core needs to model the system. Most subsystems,
 * however, track additional information about the devices they host. As a
 * result, it is rare for devices to be represented by bare device structures;
 * instead, that structure, like kobject structures, is usually embedded within
 * a higher-level representation of the device.
 */
 struct device {
    struct device       *parent;

    struct device_private   *p;

    struct kobject kobj;
    const char      *init_name; /* initial name of the device */
    const struct device_type *type;

    struct mutex        mutex;  /* mutex to synchronize calls to
                     * its driver.
                     */

    struct bus_type *bus;       /* type of bus device is on */
    struct device_driver *driver;   /* which driver has allocated this
                       device */
    void        *platform_data; /* Platform specific data, device
                       core doesn't touch it */
    struct dev_pm_info  power;
    struct dev_pm_domain    *pm_domain;

#ifdef CONFIG_PINCTRL
    struct dev_pin_info *pins;
#endif

#ifdef CONFIG_NUMA
    int     numa_node;  /* NUMA node this device is close to */
#endif
    u64     *dma_mask;  /* dma mask (if dma'able device) */
    u64     coherent_dma_mask;/* Like dma_mask, but for
                         alloc_coherent mappings as
                         not all hardware supports
                         64 bit addresses for consistent
                         allocations such descriptors. */

    struct device_dma_parameters *dma_parms;

    struct list_head    dma_pools;  /* dma pools (if dma'ble) */

    struct dma_coherent_mem *dma_mem; /* internal for coherent mem
                         override */
#ifdef CONFIG_CMA
    struct cma *cma_area;       /* contiguous memory area for dma
                       allocations */
#endif
    /* arch specific additions */
    struct dev_archdata archdata;

    struct device_node  *of_node; /* associated device tree node */
    struct acpi_dev_node    acpi_node; /* associated ACPI device node */

    dev_t           devt;   /* dev_t, creates the sysfs "dev" */
    u32         id; /* device instance */

    spinlock_t      devres_lock;
    struct list_head    devres_head;

    struct klist_node   knode_class;
    struct class        *class;
    const struct attribute_group **groups;  /* optional groups */

    void    (*release)(struct device *dev);
    struct iommu_group  *iommu_group;
}

我们不再深入研究这个结构体，第一次，因为它上面本身就有大概的说明，第二我们只是研究平台设备，所以不便深入研究这个，可能说以后有机会再深入看看吧。

resource：

/*
 * Resources are tree-like, allowing
 * nesting etc..
 */
struct resource {
    resource_size_t start;//描述设备实体在cpu总线上的线性起始物理地址
    resource_size_t end;//描述设备实体在cpu总线上的线性结尾物理地址
    const char *name;
    unsigned long flags;//描述这个设备实体的一些共性和特性的标志位
    struct resource *parent, *sibling, *child;//分别为指向父亲、兄弟和子资源的指针
};

platform_device_id:

struct platform_device_id {
    char name[PLATFORM_NAME_SIZE];//.name
    kernel_ulong_t driver_data;//驱动数据
};
其中：typedef unsigned long kernel_ulong_t;

后面两个结构体暂时不做了解，目前用不到：mfd_cell 和 pdev_archdata。

---

那么这里我们已经把一个platform_device 分析的差不多了。下来构造一个led平台设备：

static struct platform_device smdkv210_leds ={  
    .name   = "leds-gpio",  
    .dev    ={      
                .platform_data = &smdkv210_leds_pdata,  
             }, 
    .id = -1,//-1代表PLATFORM_DEVID_NONE
};
static struct gpio_led_platform_data smdkv210_leds_pdata ={
    .num_leds   = ARRAY_SIZE(leds), 
    .leds       = leds,
};
static struct gpio_led leds[] ={
    [0]    ={       
        .name   ="led0",            
        .gpio   = S5PV210_GPJ2(0),      
        .active_low = 1,        
        .default_state = LEDS_GPIO_DEFSTATE_OFF,        
        },
    [1]    ={       
        .name   ="led1",        
        .gpio   = S5PV210_GPJ2(1),      
        .active_low = 1,        
        .default_state = LEDS_GPIO_DEFSTATE_OFF,        
        },
};
其中：void     *platform_data；

这边一个平台设备定义成功。接下来，我们看看平台设备是如何被添加进到平台设备总线下面的：

platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices));

/**
 * platform_add_devices - add a numbers of platform devices
 * @devs: array of platform devices to add
 * @num: number of platform devices in array
 */
int platform_add_devices(struct platform_device **devs, int num)
{
    int i, ret = 0;

    for (i = 0; i < num; i++) {
        ret = platform_device_register(devs[i]);
        if (ret) {
            while (--i >= 0)
                platform_device_unregister(devs[i]);
            break;
        }
    }

    return ret;
}

这边添加一组平台设备到平台总线。
platform_add_devices这个函式没有什么好解释的，注册所有的平台设备，注册失败的话就注销这个设备。
全部注册成功，返回0.
接下来：

/**
 * platform_device_register - add a platform-level device
 * @pdev: platform device we're adding
 */
int platform_device_register(struct platform_device *pdev)
{
    device_initialize(&pdev->dev);//初始化平台设备下面的dev结构体
    arch_setup_pdev_archdata(pdev);
    return platform_device_add(pdev);//将平台设备添加到平台设备列表中，并返回操作结果
}

接下面分别分析这其中的两个函数，中间那个函数先不看，用于初始化平台设备的archdata结构体

/**
 * device_initialize - init device structure.
 * @dev: device.
 *
 * This prepares the device for use by other layers by initializing
 * its fields.
 * It is the first half of device_register(), if called by
 * that function, though it can also be called separately, so one
 * may use @dev's fields. In particular, get_device()/put_device()
 * may be used for reference counting of @dev after calling this
 * function.
 *
 * All fields in @dev must be initialized by the caller to 0, except
 * for those explicitly set to some other value.  The simplest
 * approach is to use kzalloc() to allocate the structure containing
 * @dev.
 *
 * NOTE: Use put_device() to give up your reference instead of freeing
 * @dev directly once you have called this function.
 */
void device_initialize(struct device *dev)
{
    dev->kobj.kset = devices_kset;
    kobject_init(&dev->kobj, &device_ktype);
    INIT_LIST_HEAD(&dev->dma_pools);
    mutex_init(&dev->mutex);
    lockdep_set_novalidate_class(&dev->mutex);
    spin_lock_init(&dev->devres_lock);
    INIT_LIST_HEAD(&dev->devres_head);
    device_pm_init(dev);
    set_dev_node(dev, -1);
}

这边先不作研究，能力有限，下次再更新

/**
 * platform_device_add - add a platform device to device hierarchy
 * @pdev: platform device we're adding
 *
 * This is part 2 of platform_device_register(), though may be called
 * separately _iff_ pdev was allocated by platform_device_alloc().
 */
int platform_device_add(struct platform_device *pdev)
{
    int i, ret;

    if (!pdev)
        return -EINVAL;

    if (!pdev->dev.parent)
        pdev->dev.parent = &platform_bus;//如果设备无父节点，那就直接挂在platform的总线上
    pdev->dev.bus = &platform_bus_type;//总线类型为platform总线

    switch (pdev->id) {
    default:
        dev_set_name(&pdev->dev, "%s.%d", pdev->name,  pdev->id);//用平台设备的name，id参数填充平台设备的dev结构体
        break;
    case PLATFORM_DEVID_NONE:
        dev_set_name(&pdev->dev, "%s", pdev->name);//只填充name，不填充ID
        break;
    case PLATFORM_DEVID_AUTO:
        /*
         * Automatically allocated device ID. We mark it as such so
         * that we remember it must be freed, and we append a suffix
         * to avoid namespace collision with explicit IDs.
         */
        ret = ida_simple_get(&platform_devid_ida, 0, 0, GFP_KERNEL);
        if (ret < 0)
            goto err_out;
        pdev->id = ret;
        pdev->id_auto = true;
        dev_set_name(&pdev->dev, "%s.%d.auto", pdev->name, pdev->id);//自动获取ID，并填充name和id到dev结构体
        break;
    }
    /*将资源列表放到资源树中进行管理*/
    for (i = 0; i < pdev->num_resources; i++) {
        struct resource *p, *r = &pdev->resource[i];

        if (r->name == NULL)
            r->name = dev_name(&pdev->dev);

        p = r->parent;//p指向平台设备资源的父设备，如果父设备不为空，
        则通过平台资源的资源类型flag来获取P（父设备资源列表）的指针
        if (!p) {
            if (resource_type(r) == IORESOURCE_MEM)//资源类型为memory
                p = &iomem_resource;
            else if (resource_type(r) == IORESOURCE_IO)//资源类型为IO资源
                p = &ioport_resource;
        }
        //如果P为空，把平台设备的资源添加到资源树中进行管理。
        //如果P不为空，将平台设备的资源列表和资源列表父设备的资源列表一起加入到资源树中管理
        if (p && insert_resource(p, r)) {
            dev_err(&pdev->dev, "failed to claim resource %d\n", i);
            ret = -EBUSY;
            goto failed;
        }
    }

    pr_debug("Registering platform device '%s'. Parent at %s\n",
         dev_name(&pdev->dev), dev_name(pdev->dev.parent));

    ret = device_add(&pdev->dev);//添加到设备树中去
    if (ret == 0)
        return ret;

 failed:
    if (pdev->id_auto) {
        ida_simple_remove(&platform_devid_ida, pdev->id);
        pdev->id = PLATFORM_DEVID_AUTO;
    }

    while (--i >= 0) {
        struct resource *r = &pdev->resource[i];
        unsigned long type = resource_type(r);

        if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
            release_resource(r);
    }

 err_out:
    return ret;
} 

其中此函数中的几个函数原型：

/**
 * dev_set_name - set a device name
 * @dev: device
 * @fmt: format string for the device's name
 */
int dev_set_name(struct device *dev, const char *fmt, ...)
{
    va_list vargs;
    int err;

    va_start(vargs, fmt);
    err = kobject_set_name_vargs(&dev->kobj, fmt, vargs);
    va_end(vargs);
    return err;
}
struct resource iomem_resource = {
    .name   = "PCI mem",
    .start  = 0,
    .end    = -1,
    .flags  = IORESOURCE_MEM,
};
struct resource ioport_resource = {
    .name   = "PCI IO",
    .start  = 0,
    .end    = IO_SPACE_LIMIT,
    .flags  = IORESOURCE_IO,
};
/**
 * insert_resource - Inserts a resource in the resource tree
 * @parent: parent of the new resource
 * @new: new resource to insert
 *
 * Returns 0 on success, -EBUSY if the resource can't be inserted.
 */
int insert_resource(struct resource *parent, struct resource *new)
{
    struct resource *conflict;

    conflict = insert_resource_conflict(parent, new);
    return conflict ? -EBUSY : 0;
}

先说一下resource扩展出的两颗树，一个针对于IO，一个针对对mem。
在Linux内核中，访问外设上的IO Port必须通过IO Port的寻址方式。而访问IO Mem就比较罗嗦，外部MEM不能和主存一样访问，因为外部MEM是没有在系统中注册的。访问外部IO MEM必须通过remap映射到内核的MEM空间后才能访问。为了达到接口的同一性，内核提供了IO Port到IO Mem的映射函数。映射后IO Port就可以看作是IO Mem，按照IO Mem的访问方式即可。
再来，设备的添加：

/**
 * device_add - add device to device hierarchy.
 * @dev: device.
 *
 * This is part 2 of device_register(), though may be called
 * separately _iff_ device_initialize() has been called separately.
 *
 * This adds @dev to the kobject hierarchy via kobject_add(), adds it
 * to the global and sibling lists for the device, then
 * adds it to the other relevant subsystems of the driver model.
 *
 * Do not call this routine or device_register() more than once for
 * any device structure.  The driver model core is not designed to work
 * with devices that get unregistered and then spring back to life.
 * (Among other things, it's very hard to guarantee that all references
 * to the previous incarnation of @dev have been dropped.)  Allocate
 * and register a fresh new struct device instead.
 *
 * NOTE: _Never_ directly free @dev after calling this function, even
 * if it returned an error! Always use put_device() to give up your
 * reference instead.
 */
 int device_add(struct device *dev)
 {
    struct device *parent = NULL;
    struct kobject *kobj;
    struct class_interface *class_intf;
    int error = -EINVAL;

    dev = get_device(dev);
    if (!dev)
        goto done;

    if (!dev->p) {
        error = device_private_init(dev);
        if (error)
            goto done;
    }

    /*
     * for statically allocated devices, which should all be converted
     * some day, we need to initialize the name. We prevent reading back
     * the name, and force the use of dev_name()
     */
    if (dev->init_name) {
        dev_set_name(dev, "%s", dev->init_name);//initial the name dev->kobj->name=dev->init_name
        dev->init_name = NULL;
    }

    /* subsystems can specify simple device enumeration */
    //initial the name dev->kobj->name=dev->bus->dev_name
    if (!dev_name(dev) && dev->bus && dev->bus->dev_name)
        dev_set_name(dev, "%s%u", dev->bus->dev_name, dev->id);

    if (!dev_name(dev)) {
        error = -EINVAL;
        goto name_error;
    }

    pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
    //get the dev->parent's dev pointer
    parent = get_device(dev->parent);
    kobj = get_device_parent(dev, parent);//get dev->parent->kobj
    //if dev->parent->kobj exist, initial the dev->kobj->parent=dev->parent->kobj
    if (kobj)
        dev->kobj.parent = kobj;

    /* use parent numa_node */
    if (parent)
        set_dev_node(dev, dev_to_node(parent));

    /* first, register with generic layer. */
    /* we require the name to be set before, and pass NULL */
    error = kobject_add(&dev->kobj, dev->kobj.parent, NULL);/*kobj arg set*/
    if (error)
        goto Error;

    /* notify platform of device entry */
    if (platform_notify)
        platform_notify(dev);
//device_create_file - create sysfs attribute file for device.uevent attr
    error = device_create_file(dev, &uevent_attr);
    if (error)
        goto attrError;

    if (MAJOR(dev->devt)) {
    //device_create_file - create sysfs attribute file for device.devt attr
        error = device_create_file(dev, &devt_attr);
        if (error)
            goto ueventattrError;

        error = device_create_sys_dev_entry(dev);//dev entry
        if (error)
            goto devtattrError;

        devtmpfs_create_node(dev);//dev node
    }

    error = device_add_class_symlinks(dev);
    if (error)
        goto SymlinkError;
    error = device_add_attrs(dev);
    if (error)
        goto AttrsError;
    error = bus_add_device(dev);
    if (error)
        goto BusError;
    error = dpm_sysfs_add(dev);
    if (error)
        goto DPMError;
    device_pm_add(dev);

    /* Notify clients of device addition.  This call must come
     * after dpm_sysfs_add() and before kobject_uevent().
     */
    if (dev->bus)
        blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
                         BUS_NOTIFY_ADD_DEVICE, dev);

    kobject_uevent(&dev->kobj, KOBJ_ADD);
    bus_probe_device(dev);//probe device
    if (parent)
        klist_add_tail(&dev->p->knode_parent,
                   &parent->p->klist_children);

    if (dev->class) {
        mutex_lock(&dev->class->p->mutex);
        /* tie the class to the device */
        klist_add_tail(&dev->knode_class,
                   &dev->class->p->klist_devices);

        /* notify any interfaces that the device is here */
        list_for_each_entry(class_intf,
                    &dev->class->p->interfaces, node)
            if (class_intf->add_dev)
                class_intf->add_dev(dev, class_intf);
        mutex_unlock(&dev->class->p->mutex);
    }
done:
    put_device(dev);
    return error;
 DPMError:
    bus_remove_device(dev);
 BusError:
    device_remove_attrs(dev);
 AttrsError:
    device_remove_class_symlinks(dev);
 SymlinkError:
    if (MAJOR(dev->devt))
        devtmpfs_delete_node(dev);
    if (MAJOR(dev->devt))
        device_remove_sys_dev_entry(dev);
 devtattrError:
    if (MAJOR(dev->devt))
        device_remove_file(dev, &devt_attr);
 ueventattrError:
    device_remove_file(dev, &uevent_attr);
 attrError:
    kobject_uevent(&dev->kobj, KOBJ_REMOVE);
    kobject_del(&dev->kobj);
 Error:
    cleanup_device_parent(dev);
    if (parent)
        put_device(parent);
name_error:
    kfree(dev->p);
    dev->p = NULL;
    goto done;
}

坦白讲，这边的内核看的懂很难很难，中秋看了好久其实也看不太懂。还是在看了许多相关视频的基础上。
但不管怎样，学习还是要继续下去。虽然内核大部分的代码都是用C写的，可是里面已经有了c++的思想。我自认为c语言学的不是很好，虽然现在有许多语言，可是一门c都学不精，又何必贪多呢！可以这样讲，如果你能把内核代码理解个七七八八，我觉得还是不愁吃喝的，而且待遇不会低。

这边我就先不更了，只能说以后有能力了，再深入去理解这些东西。

LED平台设备的添加：

/*LED*/
static struct gpio_led leds[] ={
    [0]    ={
        .name   ="led0",
        .default_trigger = "heartbeat",
        .gpio   = S5PV210_GPJ2(0),
        .active_low = 1,
        .default_state = LEDS_GPIO_DEFSTATE_OFF, 
        },
    [1]    ={
        .name   = "led1",
        .gpio   = S5PV210_GPJ2(1),
        .active_low = 1,
        .default_state = LEDS_GPIO_DEFSTATE_OFF, 
        },
    [2]    ={
        .name   = "led2",
        .gpio   = S5PV210_GPJ2(2),
        .active_low = 1,
        .default_state = LEDS_GPIO_DEFSTATE_OFF, 
        },
    [3]    ={
        .name   = "led3",
        .gpio   = S5PV210_GPJ2(3),
        .active_low = 1,
        .default_state = LEDS_GPIO_DEFSTATE_OFF, 
        },
};
static struct gpio_led_platform_data smdkv210_leds_pdata ={
    .num_leds   = ARRAY_SIZE(leds),
    .leds       = leds,
};
static struct platform_device smdkv210_leds ={
    .name   = "leds-gpio",
    .dev    ={
        .platform_data = &smdkv210_leds_pdata,
    },
    .id = -1,
};

这边构造出平台设备，然后把 smdkv210_leds加入到平台设备列表中。当然最后要打开led 驱动的支持。
配置内核：Devices drivers–>LED support–> LED class support
–>LED Support for GPIO connected LEDs
make uImage

重新利用uboot 载入内核，当进入到 busybox配置好的NFS文件系统后会有：

平台设备添加直观上看就是把挂载到同一总线下的驱动和设备绑定成功。
实际的效果是分别在某些目录下生成了对应的设备，驱动目录。里面又有具体的属性…
当然这篇文章可能只能先这样了，等到时机成熟，有能力时再做笔记。