spi（5）參考資料

OMAP3630下的Linux SPI總線驅動分析(2)

4 OMAP3630 SPI 控制器驅動

      在Linux內核中，SPI 控制器驅動位於drivers/spi目錄下，OMAP3630 的spi控制器驅動程序爲omap2_mcspi.c。
      SPI 控制器驅動的註冊採用Platform設備和驅動機制。

4.1 SPI 控制器的Platform device

      Android2.1中Platform device的註冊代碼位於內核的arch/arm/mach-omap2/devices.c中。

4.1.1 Platform device的定義

       在文件arch/arm/mach-omap2/devices.c中，Platform device定義如下：

<span style="font-size:18px;">static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
    .num_cs     = 4,
};

static struct resource omap2_mcspi1_resources[] = {
    {
        .start      = OMAP2_MCSPI1_BASE,
        .end        = OMAP2_MCSPI1_BASE + 0xff,
        .flags      = IORESOURCE_MEM,
    },
};

static struct platform_device omap2_mcspi1 = {
    .name       = "omap2_mcspi",
    .id     = 1,
    .num_resources  = ARRAY_SIZE(omap2_mcspi1_resources),
    .resource   = omap2_mcspi1_resources,
    .dev        = {
        .platform_data = &omap2_mcspi1_config,
    },
};

static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
    .num_cs     = 2,
};

static struct resource omap2_mcspi2_resources[] = {
    {
        .start      = OMAP2_MCSPI2_BASE,
        .end        = OMAP2_MCSPI2_BASE + 0xff,
        .flags      = IORESOURCE_MEM,
    },
};

static struct platform_device omap2_mcspi2 = {
    .name       = "omap2_mcspi",
    .id     = 2,
    .num_resources  = ARRAY_SIZE(omap2_mcspi2_resources),
    .resource   = omap2_mcspi2_resources,
    .dev        = {
        .platform_data = &omap2_mcspi2_config,
    },
};

#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
    .num_cs     = 2,
};

static struct resource omap2_mcspi3_resources[] = {
    {
    .start      = OMAP2_MCSPI3_BASE,
    .end        = OMAP2_MCSPI3_BASE + 0xff,
    .flags      = IORESOURCE_MEM,
    },
};

static struct platform_device omap2_mcspi3 = {
    .name       = "omap2_mcspi",
    .id     = 3,
    .num_resources  = ARRAY_SIZE(omap2_mcspi3_resources),
    .resource   = omap2_mcspi3_resources,
    .dev        = {
        .platform_data = &omap2_mcspi3_config,
    },
};
#endif

#ifdef CONFIG_ARCH_OMAP3
static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
    .num_cs     = 1,
};

static struct resource omap2_mcspi4_resources[] = {
    {
        .start      = OMAP2_MCSPI4_BASE,
        .end        = OMAP2_MCSPI4_BASE + 0xff,
        .flags      = IORESOURCE_MEM,
    },
};

static struct platform_device omap2_mcspi4 = {
    .name       = "omap2_mcspi",
    .id     = 4,
    .num_resources  = ARRAY_SIZE(omap2_mcspi4_resources),
    .resource   = omap2_mcspi4_resources,
    .dev        = {
        .platform_data = &omap2_mcspi4_config,
    },
};
#endif</span>

        可以看到，這邊定義了4個SPI控制器的Platform device，id分別爲“1，2，3, 4”，name都爲“omap2_mcspi”，變量resource中定義了適配器的寄存器基地址。

4.1.2 Platform device的註冊

        Platform device的註冊是由內核啓動時完成的。在文件arch/arm/mach-omap2/devices.c中，具體的代碼如下：

<span style="font-size:18px;">static int __init omap2_init_devices(void)
{
    /* please keep these calls, and their implementations above,
     * in alphabetical order so they're easier to sort through.
     */
    omap_hsmmc_reset();
    omap_init_camera();
    omap_init_mbox();
    omap_init_mcspi();
    omap_init_sti();
    omap_init_sha1_md5();

    return 0;
}
arch_initcall(omap2_init_devices);</span><span style="font-family:Arial, Verdana, sans-serif;"><span style="white-space: normal;">
</span></span>

        內核啓動時會調用函數omap2_init_devices()，函數omap2_init_devices ()再調到spi的初始化函數omap_init_mcspi()，omap_init_mcspi()代碼如下：

<span style="font-size:18px;">static void omap_init_mcspi(void)
{
    platform_device_register(&omap2_mcspi1);
    platform_device_register(&omap2_mcspi2);
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
    if (cpu_is_omap2430() || cpu_is_omap343x())
        platform_device_register(&omap2_mcspi3);
#endif
#ifdef CONFIG_ARCH_OMAP3
    if (cpu_is_omap343x())
        platform_device_register(&omap2_mcspi4);
#endif
}</span>

       函數omap2_init_devices()通過調用platform_device_register()將Platform device註冊到Platform總線上，完成註冊後，寄存器的基地址等信息會在設備樹中描述了，此後只需利用platform_get_resource等標準接口自動獲取即可，實現了驅動和資源的分離。

4.2 SPI 控制器的Platform driver

      Andrord 2.1中Platform driver的註冊代碼位於內核的drivers/spi/omap2_mcspi.c中，該驅動的註冊目的是初始化OMAP3630的SPI 控制器，提供SPI總線數據傳輸的具體實現，並且向spi core層註冊spi 控制器。

4.2.1 Platform driver的定義

       在文件drivers/spi/omap2_mcspi.c中，platform driver定義如下：

<span style="font-size:18px;">static struct platform_driver omap2_mcspi_driver = {
    .driver = {
        .name =     "omap2_mcspi",
        .owner =    THIS_MODULE,
    },
    .remove =   __exit_p(omap2_mcspi_remove),
};</span>

       可以看到，這裏的name字段與4.1.1中定義的Platform device的name字段相同，用於驅動和設備匹配時使用。

4.2.2 Platform driver的註冊

       在文件drivers/spi/omap2_mcspi.c中，platform driver註冊如下：

<span style="font-size:18px;">static int __init omap2_mcspi_init(void)
{
    omap2_mcspi_wq = create_singlethread_workqueue(
                omap2_mcspi_driver.driver.name);
    if (omap2_mcspi_wq == NULL)
        return -1;
    return platform_driver_probe(&omap2_mcspi_driver, omap2_mcspi_probe);
}
subsys_initcall(omap2_mcspi_init); </span>

        在內核啓動時會調用函數omap2_mcspi_init()，該函數先創建一個名字爲"omap2_mcspi"的workqueue，第二章中提到過spi的數據傳輸是基於workqueue的，所以這邊的初始化函數會首先創建一個workqueue。
        Workqueue創建成功後纔會用函數platform_driver_probe()來註冊Platform driver，該函數是帶有probe函數的平臺驅動註冊函數，用於非hot-plug設備。
        註冊時，會掃描platform bus上的所有設備，由於匹配因子name爲" omap2_mcspi "，因此與4.1.1節中註冊的Platform device匹配成功，於是函數omap2_mcspi_probe()將被調用，控制器device和driver將被綁定起來。
        在文件drivers/spi/omap2_mcspi.c中會涉及到一個數據結構omap2_mcspi，這個結構定義了專門針對omap3630的SPI控制器結構，代碼如下：

<span style="font-size:18px;">struct omap2_mcspi {
    struct work_struct  work;
    /* lock protects queue and registers */
    spinlock_t      lock;
    struct list_head    msg_queue;
    struct spi_master   *master;
    struct clk      *ick;
    struct clk      *fck;
    /* Virtual base address of the controller */
    void __iomem        *base;
    unsigned long       phys;
    /* SPI1 has 4 channels, while SPI2 has 2 */
    struct omap2_mcspi_dma  *dma_channels;
};</span>

       msg_queue對應消息隊列。
       master對應通用的spi控制器結構。
       ick和fck分別對應接口時鐘和功能時鐘。
       base對應SPI控制器寄存器的虛擬地址。
       phys對應SPI控制器寄存器的物理地址。
       dma_channels對應SPI控制器的DMA通道。  
      函數omap2_mcspi_probe()的執行流程如下圖：

圖4.1 omap2_mcspi_probe()的執行流程

       函數omap2_mcspi_probe()的簡要代碼如下：

<span style="font-size:18px;">static int __init omap2_mcspi_probe(struct platform_device *pdev)
{
    struct spi_master   *master;
    struct omap2_mcspi  *mcspi;
    ……

    switch (pdev->id) {
    case 1:
        rxdma_id = spi1_rxdma_id;
        txdma_id = spi1_txdma_id;
        num_chipselect = 4;
        break;
    case 2:
        ……
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
    case 3:
        ……
#endif
#ifdef CONFIG_ARCH_OMAP3
    case 4:
        ……
#endif
    default:
        return -EINVAL;
    }

    master = spi_alloc_master(&pdev->dev, sizeof *mcspi);
    ……
    if (pdev->id != -1)
        master->bus_num = pdev->id;

    master->setup = omap2_mcspi_setup;
    master->transfer = omap2_mcspi_transfer;
    master->cleanup = omap2_mcspi_cleanup;
    master->num_chipselect = num_chipselect;

    dev_set_drvdata(&pdev->dev, master);

    mcspi = spi_master_get_devdata(master);
    mcspi->master = master;

    r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    if (r == NULL) {
        status = -ENODEV;
        goto err1;
    }
    if (!request_mem_region(r->start, (r->end - r->start) + 1,
            pdev->dev.bus_id)) {
        status = -EBUSY;
        goto err1;
    }

    mcspi->phys = r->start;
    mcspi->base = ioremap(r->start, r->end - r->start + 1);
    ……
    INIT_WORK(&mcspi->work, omap2_mcspi_work);
    spin_lock_init(&mcspi->lock);
    INIT_LIST_HEAD(&mcspi->msg_queue);

    mcspi->ick = clk_get(&pdev->dev, "mcspi_ick");
   ……
    mcspi->fck = clk_get(&pdev->dev, "mcspi_fck");
    ……
    mcspi->dma_channels = kcalloc(master->num_chipselect,
            sizeof(struct omap2_mcspi_dma),
            GFP_KERNEL);
    ……
    for (i = 0; i < num_chipselect; i++) {
        mcspi->dma_channels[i].dma_rx_channel = -1;
        mcspi->dma_channels[i].dma_rx_sync_dev = rxdma_id[i];
        mcspi->dma_channels[i].dma_tx_channel = -1;
        mcspi->dma_channels[i].dma_tx_sync_dev = txdma_id[i];
    }
    ……
    status = spi_register_master(master);
    ……
    return status;
    ……
}</span>

        可以看到，omap2_mcspi_probe()函數會給spi_master的賦setup，transfer等初始化以及數據傳輸函數，爲了能提高spi的傳輸速度，一般會採用DMA模式，最後使用了spi_register_master ()將spi控制器註冊到spi core層，在4.1.1節中定義了4個SPI總線設備，所以這裏會建立4個spi控制器，總線號分別爲1，2，3，4。

5 OMAP3630 SPI 設備驅動

       在Linux內核中，SPI 設備可以是各種SPI接口的設備，設備可以有不同的用途，這裏以Ti的觸摸屏控制器芯片tsc2005爲例來介紹SPI設備驅動的註冊過程，對應的設備驅動程序爲tsc2005.c，位於目錄drivers/input/touchscreen下。

5.1 Tsc2005設備註冊

       Tsc2005設備的創建以及註冊分爲兩步。

5.1.1 將tsc2005設備信息加入到設備鏈表

       在板級初始化時將tsc2005的名稱，地址和相關的信息加入到鏈表board_list中，該鏈表定義在driver/spi/spi.c中，記錄了具體開發板上的SPI設備信息。

<span style="font-size:18px;">static LIST_HEAD(board_list);</span>

        在board-xxxx.c中，tsc2005設備信息定義如下：

<span style="font-size:18px;">static struct spi_board_info xxxx_spi_board_info[] __initdata = {
……
    {
     .modalias = "tsc2005",
     .platform_data = &tsc2005_config,
     .controller_data = &touchscreen_spi_cfg,
     .mode = SPI_MODE_1,
     .irq = OMAP_GPIO_IRQ(TS_GPIO),
     .max_speed_hz = 700000,
     .bus_num   = 0,
     .chip_select = 2,
     },
};</span>

       Tsc2005設備信息通過函數spi_register_board_info()加入到鏈表board_list中，代碼如下：

<span style="font-size:18px;">static void __init omap_xxxx_init(void)
{
    omap_i2c_init();
    ……
    spi_register_board_info(xxxx_spi_board_info,
                ARRAY_SIZE(xxxx_spi_board_info));
    ……
}</span>

       Tsc2005加入到設備鏈表board_list的流程圖如下圖：

圖5.1 tsc2005加入到SPI設備鏈表的過程

        spi_register_board_info()函數的定義在driver/spi/spi.c中，如下：

<span style="font-size:18px;">int __init spi_register_board_info(struct spi_board_info const *info, unsigned n)
{
    struct boardinfo    *bi;

    bi = kmalloc(sizeof(*bi) + n * sizeof *info, GFP_KERNEL);
    if (!bi)
        return -ENOMEM;
    bi->n_board_info = n;
    memcpy(bi->board_info, info, n * sizeof *info);

    mutex_lock(&board_lock);
    list_add_tail(&bi->list, &board_list);
    mutex_unlock(&board_lock);
    return 0;
}</span>

5.1.2 Tsc2005 spi_device的創建並添加

        Tsc2005 spi_device的創建並添加在SPI控制器驅動註冊過程中完成，SPI 控制器驅動的註冊可以參考4.2.2節，spi_register_master()函數在註冊SPI控制器驅動的過程會掃描5.1.1中提到的SPI設備鏈表board_list，如果該總線上有對應的SPI設備，則創建相應的 spi_device，並將其添加到SPI的設備鏈表中。流程圖如下所示：

圖5.2創建並添加spi_device

        相應的代碼位於driver/spi/spi.c，如下：

<span style="font-size:18px;">int spi_register_master(struct spi_master *master)
{
    static atomic_t     dyn_bus_id = ATOMIC_INIT((1<<15) - 1);
    struct device       *dev = master->dev.parent;
    int         status = -ENODEV;
    int         dynamic = 0;
    ……
    status = device_add(&master->dev);
    ……
    scan_boardinfo(master);
    ……
}</span>

       函數spi_register_master()調用scan_boardinfo()函數掃描板級的設備。

<span style="font-size:18px;">static void scan_boardinfo(struct spi_master *master)
{
    struct boardinfo    *bi;

    mutex_lock(&board_lock);
    list_for_each_entry(bi, &board_list, list) {
        struct spi_board_info   *chip = bi->board_info;
        unsigned        n;

        for (n = bi->n_board_info; n > 0; n--, chip++) {
            if (chip->bus_num != master->bus_num)
                continue;
            /* NOTE: this relies on spi_new_device to
             * issue diagnostics when given bogus inputs
             */
            (void) spi_new_device(master, chip);
        }
    }
    mutex_unlock(&board_lock);
}</span>

        在scan_boardinfo()函數中遍歷SPI設備鏈表board_list，設備的總線號和控制器的總線號相等，則使用函數spi_new_device()創建該設備。

<span style="font-size:18px;">struct spi_device *spi_new_device(struct spi_master *master,
                  struct spi_board_info *chip)
{
    struct spi_device   *proxy;
    int         status;
    ……
    proxy = spi_alloc_device(master);
    ……
    proxy->chip_select = chip->chip_select;
    proxy->max_speed_hz = chip->max_speed_hz;
    proxy->mode = chip->mode;
    proxy->irq = chip->irq;
    strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
    proxy->dev.platform_data = (void *) chip->platform_data;
    proxy->controller_data = chip->controller_data;
    proxy->controller_state = NULL;

    status = spi_add_device(proxy);
    if (status < 0) {
        spi_dev_put(proxy);
        return NULL;
    }

    return proxy;
}</span>

       在函數spi_new_device ()中使用函數spi_alloc_device()創建一個spi_device，spi_alloc_device()代碼如下：

<span style="font-size:18px;">struct spi_device *spi_alloc_device(struct spi_master *master)
{
    struct spi_device   *spi;
    struct device       *dev = master->dev.parent;
    if (!spi_master_get(master))
        return NULL;
    spi = kzalloc(sizeof *spi, GFP_KERNEL);
    ……
    spi->master = master;
    spi->dev.parent = dev;
    spi->dev.bus = &spi_bus_type;
    spi->dev.release = spidev_release;
    device_initialize(&spi->dev);
    return spi;
}</span>

       首先爲spi_device分配內存空間，接着初始化該結構體，將該設備的bus初始化爲spi_bus_type，說明該設備將被掛接到SPI總線上，方便與spi driver匹配，初始化master爲當前的SPI控制器。
       從spi_alloc_device()函數返回後繼續初始化spi_device結構體的chip_select，mode，modalias, controller_data等變量，這裏的proxy->modalias被初始化爲chip->modalias，在5.1.1中，chip->modalias初始化爲“tsc2005”，proxy->modalias後面會用於spi device和spi driver匹配時使用，最後調用spi_add_device ()將該SPI設備proxy添加到SPI設備鏈表中。

<span style="font-size:18px;">int spi_add_device(struct spi_device *spi)
{
    static DEFINE_MUTEX(spi_add_lock);
    struct device *dev = spi->master->dev.parent;
    int status;
    ……
    if (bus_find_device_by_name(&spi_bus_type, NULL, dev_name(&spi->dev))
            != NULL) {
        dev_err(dev, "chipselect %d already in use\n",
                spi->chip_select);
        status = -EBUSY;
        goto done;
    }
    ……
    status = spi->master->setup(spi);
    ……
    /* Device may be bound to an active driver when this returns */
    status = device_add(&spi->dev);
    …….
 }</span>

        函數spi_add_device ()進一步初始化SPI設備proxy，驗證在spi_bus_type是否已存在該設備，如果沒有則初始化該設備所在的spi控制器，最後使用device_add(&spi->dev)添加該SPI設備proxy到SPI設備鏈表中。

5.2 Tsc2005設備驅動註冊

      在driver/input/touchscreen/tsc2005.c中，定義了tsc2005的設備驅動，代碼如下：

<span style="font-size:18px;">static struct spi_driver tsc2005_driver = {
    .driver = {
        .name = "tsc2005",
        .owner = THIS_MODULE,
    },
#ifdef CONFIG_PM
    .suspend = tsc2005_suspend,
    .resume = tsc2005_resume,
#endif
    .probe = tsc2005_probe,
    .remove = __devexit_p(tsc2005_remove),
};</span>

        註冊的簡要示意圖如下:

圖5.3 tsc2005設備驅動的註冊

       相應的代碼位於driver/input/touchscreen/tsc2005.c和driver/spi/spi.c。

<span style="font-size:18px;">static int __init tsc2005_init(void)
{
    printk(KERN_INFO "TSC2005 driver initializing\n");

    return spi_register_driver(&tsc2005_driver);
}
module_init(tsc2005_init);</span>

      在模塊加載的時候首先調用tsc2005_init()，然後tsc2005_init()調用函數spi_register_driver()註冊tsc2005_driver結構體。

<span style="font-size:18px;">int spi_register_driver(struct spi_driver *sdrv)
{
    sdrv->driver.bus = &spi_bus_type;
    if (sdrv->probe)
        sdrv->driver.probe = spi_drv_probe;
    if (sdrv->remove)
        sdrv->driver.remove = spi_drv_remove;
    if (sdrv->shutdown)
        sdrv->driver.shutdown = spi_drv_shutdown;
    return driver_register(&sdrv->driver);
} </span>

       函數spi_register_driver()初始化該驅動的總線爲spi_bus_type，然後使用函數driver_register(&sdrv->driver)註冊該驅動，因此內核會在SPI總線上遍歷所有SPI設備，由於該tsc2005 設備驅動的匹配因子name變量爲“tsc2005”，因此正好和在5.1.2裏創建的chip->modalias爲“tsc2005”的SPI 設備匹配。因此SPI設備驅動的probe函數tsc2005_probe()將會被調用，具體代碼如下：

<span style="font-size:18px;">static int __devinit tsc2005_probe(struct spi_device *spi)
{
    struct tsc2005          *tsc;
    struct tsc2005_platform_data    *pdata = spi->dev.platform_data;
    int r;
    ……
    tsc = kzalloc(sizeof(*tsc), GFP_KERNEL);
    ……
    dev_set_drvdata(&spi->dev, tsc);
    tsc->spi = spi;
    spi->dev.power.power_state = PMSG_ON;
    spi->mode = SPI_MODE_0;
    spi->bits_per_word = 8;
    ……
    spi_setup(spi);
    r = tsc2005_ts_init(tsc, pdata);
    ……
}</span>

       在tsc2005_probe()函數中，完成一些具體tsc2005設備相關的初始化等操作，這邊就不再詳述。

6 用戶空間的支持

       和I2C一樣，SPI也具有一個通用的設備的動程序，通過一個帶有操作集file_operations的標準字符設備驅動爲用戶空間提供了訪問接口。
       此驅動模型是針對SPI設備的，只有註冊board info時modalias是”spidev”的才能由此驅動訪問。訪問各個slave的基本框架是一致的，具體的差異將由從設備號來體現，代碼部分位於drivers/spi/spidev.c。

6.1 Spidev的註冊

       在drivers/spi/spidev.c中，首先定義了SPI設備驅動spidev_spi：

<span style="font-size:18px;">static struct spi_driver spidev_spi = {
    .driver = {
        .name =     "spidev",
        .owner =    THIS_MODULE,
    },
    .probe =    spidev_probe,
    .remove =   __devexit_p(spidev_remove),
};</span>

      spidev_spi註冊代碼如下：

<span style="font-size:18px;">static int __init spidev_init(void)
{
    int status;
    ……
    status = register_chrdev(SPIDEV_MAJOR, "spi", &spidev_fops);
    if (status < 0)
        return status;

    spidev_class = class_create(THIS_MODULE, "spidev");
    ……
    status = spi_register_driver(&spidev_spi);
    ……
}
module_init(spidev_init);</span>

       首先註冊了一個主設備號爲SPIDEV_MAJOR，操作集爲spidev_fops，名字爲“spi”的字符設備。在文件drivers/spi/spidev.c中，SPI_MAJOR被定義爲153。在spidev.c中spidev_fops的定義如下：

<span style="font-size:18px;">static struct file_operations spidev_fops = {
    .owner =    THIS_MODULE,
    /* REVISIT switch to aio primitives, so that userspace
     * gets more complete API coverage.  It'll simplify things
     * too, except for the locking.
     */
    .write =    spidev_write,
    .read =     spidev_read,
    .unlocked_ioctl = spidev_ioctl,
    .open =     spidev_open,
    .release =  spidev_release,
};</span>

        該操作集是用戶空間訪問該字符設備的接口。
        然後調用函數spi_register_driver(&spidev_spi)將spidev_spi 驅動註冊到SPI 核心層中，spidev_spi驅動註冊過程中會掃描SPI總線上的所有SPI設備，一旦掃描到關鍵字modalias爲”spidev”的SPI設備時，則與該SPI驅動匹配，匹配函數spidev_probe()被調用，具體的註冊流程圖如下：

圖5.1 SPIdev_driver註冊過程

       spidev_probe ()函數的代碼如下：

<span style="font-size:18px;">static int spidev_probe(struct spi_device *spi)
{
    struct spidev_data  *spidev;
    int         status;
    unsigned long       minor;

    /* Allocate driver data */
    spidev = kzalloc(sizeof(*spidev), GFP_KERNEL);
    if (!spidev)
        return -ENOMEM;

    /* Initialize the driver data */
    spidev->spi = spi;
    ……
    minor = find_first_zero_bit(minors, N_SPI_MINORS);
    if (minor < N_SPI_MINORS) {
        struct device *dev;

        spidev->devt = MKDEV(SPIDEV_MAJOR, minor);
        dev = device_create(spidev_class, &spi->dev, spidev->devt,
                    spidev, "spidev%d.%d",
                    spi->master->bus_num, spi->chip_select);
        status = IS_ERR(dev) ? PTR_ERR(dev) : 0;
    } else {
        dev_dbg(&spi->dev, "no minor number available!\n");
        status = -ENODEV;
    }
    if (status == 0) {
        set_bit(minor, minors);
        list_add(&spidev->device_entry, &device_list);
    }
    …….
}</span>

        在匹配函數spidev_probe()中，會首先爲spidev_data結構體分配內存空間，該結構體定義如下：

<span style="font-size:18px;">struct spidev_data {
    dev_t           devt;
    spinlock_t      spi_lock;
    struct spi_device   *spi;
    struct list_head    device_entry;
    /* buffer is NULL unless this device is open (users > 0) */
    struct mutex        buf_lock;
    unsigned        users;
    u8          *buffer;
};</span>

       結構體中包含了spi_device結構體，device_entry鏈表頭等成員變量。
       分配完spidev_data結構體後對其進行初始化，然後創建spi設備，成功後將該spidev_data添加到device_list鏈表中，該鏈表維護這些modalias爲”spidev”的SPI設備。device_list鏈表定義在spidev.c中如下：

<span style="font-size:18px;">static LIST_HEAD(device_list);</span>

       這些SPI設備以SPIDEV_MAJOR爲主設備號，以函數find_first_zero_bit()的返回值爲從設備號創建並註冊設備節點。如果系統有udev或者是hotplug，那麼就會在/dev下自動創建相關的設備節點了，其名稱命名方式爲spidevB.C，B爲總線編號，C爲片選序號。

6.2 Spidev的打開

      Spidev的open函數如下：

<span style="font-size:18px;">static int spidev_open(struct inode *inode, struct file *filp)
{
    struct spidev_data  *spidev;
    int         status = -ENXIO;

    lock_kernel();
    mutex_lock(&device_list_lock);

    list_for_each_entry(spidev, &device_list, device_entry) {
        if (spidev->devt == inode->i_rdev) {
            status = 0;
            break;
        }
    }
    if (status == 0) {
        if (!spidev->buffer) {
            spidev->buffer = kmalloc(bufsiz, GFP_KERNEL);
            if (!spidev->buffer) {
                dev_dbg(&spidev->spi->dev, "open/ENOMEM\n");
                status = -ENOMEM;
            }
        }
        if (status == 0) {
            spidev->users++;
            filp->private_data = spidev;
            nonseekable_open(inode, filp);
        }
    } else
        pr_debug("spidev: nothing for minor %d\n", iminor(inode));

    mutex_unlock(&device_list_lock);
    unlock_kernel();
    return status;
}
</span>

       Open操作是用戶空間程序和內核驅動交互的第一步，首先會遍歷device_list鏈表，然後根據設備節點號進行匹配查找對應的spidev_data節點從而找到相應的從設備，然後給spidev分配buffer空間，最後filp的private_data被賦值爲spidev，而最終返回給用戶空間的就是這個struct file結構體。對於SPI 驅動來說，用戶空間所獲得的就是spidev這個關鍵信息，在其中可以找到所有有關的信息如spidev的SPI設備。
       用open函數將spidev設備打開以後，就可以通過ioctl函數的各種命令來對modalias爲”spidev”的SPI設備進行讀寫等操作，也可以通過 read和write函數完成對SPI設備的讀寫。
       對SPI設備的具體操作在這裏不再具體闡述，可以參看spidev.c源代碼。

7 SPI數據收發

       第二章的時候的時候已經講到過，SPI的通信是通過消息隊列機制也就是workqueue，核心思想就是要構造一個spi_message。

7.1 SPI數據收發數據結構

             SPI數據收發用到的結構體主要有兩個，spi_message和spi_transfer，兩者都定義在include/linux/spi/spi.h中。
spi_message定義如下：

<span style="font-size:18px;">/**
 * struct spi_message - one multi-segment SPI transaction
 * @transfers: list of transfer segments in this transaction
 * @spi: SPI device to which the transaction is queued
 * @is_dma_mapped: if true, the caller provided both dma and cpu virtual
 *  addresses for each transfer buffer
 * @complete: called to report transaction completions
 * @context: the argument to complete() when it's called
 * @actual_length: the total number of bytes that were transferred in all
 *  successful segments
 * @status: zero for success, else negative errno
 * @queue: for use by whichever driver currently owns the message
 * @state: for use by whichever driver currently owns the message
 *
 * A @spi_message is used to execute an atomic sequence of data transfers,
 * each represented by a struct spi_transfer.  The sequence is "atomic"
 * in the sense that no other spi_message may use that SPI bus until that
 * sequence completes.  On some systems, many such sequences can execute as
 * as single programmed DMA transfer.  On all systems, these messages are
 * queued, and might complete after transactions to other devices.  Messages
 * sent to a given spi_device are alway executed in FIFO order.
 *
 * The code that submits an spi_message (and its spi_transfers)
 * to the lower layers is responsible for managing its memory.
 * Zero-initialize every field you don't set up explicitly, to
 * insulate against future API updates.  After you submit a message
 * and its transfers, ignore them until its completion callback.
 */
struct spi_message {
    struct list_head    transfers;
    struct spi_device   *spi;
    unsigned        is_dma_mapped:1;
    /* REVISIT:  we might want a flag affecting the behavior of the
     * last transfer ... allowing things like "read 16 bit length L"
     * immediately followed by "read L bytes".  Basically imposing
     * a specific message scheduling algorithm.
     *
     * Some controller drivers (message-at-a-time queue processing)
     * could provide that as their default scheduling algorithm.  But
     * others (with multi-message pipelines) could need a flag to
     * tell them about such special cases.
     */
    /* completion is reported through a callback */
    void            (*complete)(void *context);
    void            *context;
    unsigned        actual_length;
    int         status;
    /* for optional use by whatever driver currently owns the
     * spi_message ...  between calls to spi_async and then later
     * complete(), that's the spi_master controller driver.
     */
    struct list_head    queue;
    void            *state;
};</span><span style="font-size:18px;">
</span>

        spi_message 包含了一系列spi_transfer，在所有的spi_transfer發送完畢前，SPI總線一直被佔據，其間不會出現總線衝突，因此一個spi_message是一個原子系列，這種特性非常利於複雜的SPI通信協議，如先發送命令字然後才能讀取數據。所有的spi_message都按照FIFO順序執行。
       還定義了需要發送的SPI設備，上下文信息context和傳輸完成後需要的回調函數complete等。
       spi_transfer結構體的定義如下：

<span style="font-size:18px;">/**
 * struct spi_transfer - a read/write buffer pair
 * @tx_buf: data to be written (dma-safe memory), or NULL
 * @rx_buf: data to be read (dma-safe memory), or NULL
 * @tx_dma: DMA address of tx_buf, if @spi_message.is_dma_mapped
 * @rx_dma: DMA address of rx_buf, if @spi_message.is_dma_mapped
 * @len: size of rx and tx buffers (in bytes)
 * @speed_hz: Select a speed other than the device default for this
 *      transfer. If 0 the default (from @spi_device) is used.
 * @bits_per_word: select a bits_per_word other than the device default
 *      for this transfer. If 0 the default (from @spi_device) is used.
 * @cs_change: affects chipselect after this transfer completes
 * @delay_usecs: microseconds to delay after this transfer before
 *  (optionally) changing the chipselect status, then starting
 *  the next transfer or completing this @spi_message.
 * @transfer_list: transfers are sequenced through @spi_message.transfers
 *
 * SPI transfers always write the same number of bytes as they read.
 * Protocol drivers should always provide @rx_buf and/or @tx_buf.
 * In some cases, they may also want to provide DMA addresses for
 * the data being transferred; that may reduce overhead, when the
 * underlying driver uses dma.
 *
 * If the transmit buffer is null, zeroes will be shifted out
 * while filling @rx_buf.  If the receive buffer is null, the data
 * shifted in will be discarded.  Only "len" bytes shift out (or in).
 * It's an error to try to shift out a partial word.  (For example, by
 * shifting out three bytes with word size of sixteen or twenty bits;
 * the former uses two bytes per word, the latter uses four bytes.)
 *
 * In-memory data values are always in native CPU byte order, translated
 * from the wire byte order (big-endian except with SPI_LSB_FIRST).  So
 * for example when bits_per_word is sixteen, buffers are 2N bytes long
 * (@len = 2N) and hold N sixteen bit words in CPU byte order.
 *
 * When the word size of the SPI transfer is not a power-of-two multiple
 * of eight bits, those in-memory words include extra bits.  In-memory
 * words are always seen by protocol drivers as right-justified, so the
 * undefined (rx) or unused (tx) bits are always the most significant bits.
 *
 * All SPI transfers start with the relevant chipselect active.  Normally
 * it stays selected until after the last transfer in a message.  Drivers
 * can affect the chipselect signal using cs_change.
 *
 * (i) If the transfer isn't the last one in the message, this flag is
 * used to make the chipselect briefly go inactive in the middle of the
 * message.  Toggling chipselect in this way may be needed to terminate
 * a chip command, letting a single spi_message perform all of group of
 * chip transactions together.
 *
 * (ii) When the transfer is the last one in the message, the chip may
 * stay selected until the next transfer.  On multi-device SPI busses
 * with nothing blocking messages going to other devices, this is just
 * a performance hint; starting a message to another device deselects
 * this one.  But in other cases, this can be used to ensure correctness.
 * Some devices need protocol transactions to be built from a series of
 * spi_message submissions, where the content of one message is determined
 * by the results of previous messages and where the whole transaction
 * ends when the chipselect goes intactive.
 *
 * The code that submits an spi_message (and its spi_transfers)
 * to the lower layers is responsible for managing its memory.
 * Zero-initialize every field you don't set up explicitly, to
 * insulate against future API updates.  After you submit a message
 * and its transfers, ignore them until its completion callback.
 */
struct spi_transfer {
    /* it's ok if tx_buf == rx_buf (right?)
     * for MicroWire, one buffer must be null
     * buffers must work with dma_*map_single() calls, unless
     *   spi_message.is_dma_mapped reports a pre-existing mapping
     */
    const void  *tx_buf;
    void        *rx_buf;
    unsigned    len;

    dma_addr_t  tx_dma;
    dma_addr_t  rx_dma;

    unsigned    cs_change:1;
    u8      bits_per_word;
    u16     delay_usecs;
    u32     speed_hz;

    struct list_head transfer_list;
};</span><span style="font-size:18px;">
</span>

        一個spi_transfer是以某種特性如速率、延時及字長連續傳輸的最小單位。因爲SPI是全雙工總線，只要總線上有數據傳輸，則MOSI和MISO上同時有數據採樣，對於SPI 控制器來說，其收發緩衝區中都有數據，但是對於SPI設備來說，其可以靈活的選擇tx_buf和rx_buf的設置。當發送數據時，tx_buf必須設置爲待發送的數據，rx_buf可以爲null或者指向無用的緩衝區，即不關心MISO的數據。而當接收數據時，rx_buf必須指向接收緩衝區，而tx_buf可以爲Null，則MOSI上爲全0，或者tx_buf指向不會引起從設備異常相應的數據，len爲待發送或者接收的數據長度，當然當採用DMAf方式傳輸時，必須初始化相應的DMA地址。當一系列spi_transfer構成一個spi_message時，cs_change的設置非常講究。當cs_change爲0即不變時，則可以連續對同一個設備進行數據收發；當cs_change爲1時通常用來停止command的傳輸而隨後進行數據接收。因此cs_change可以利用SPI總線構造複雜的通信協議。
        對於SPI總線協議來說，傳輸單位可以是4-32之間的任意bits，但對於SPI控制器來說，bits_per_word只能是8/16/32，即需要取整，待收發的數據在內存裏都是以主機字節序右對齊存儲，SPI控制器會自動根據傳輸單位及大小端進行轉換。

7.2 SPI數據收發的函數

       SPI數據收發的函數主要有spi_async()和spi_sync()。
       函數spi_async()定義在include/linux/spi/spi.h中，

<span style="font-size:18px;">/**
 * spi_async - asynchronous SPI transfer
 * @spi: device with which data will be exchanged
 * @message: describes the data transfers, including completion callback
 * Context: any (irqs may be blocked, etc)
 *
 * This call may be used in_irq and other contexts which can't sleep,
 * as well as from task contexts which can sleep.
 *
 * The completion callback is invoked in a context which can't sleep.
 * Before that invocation, the value of message->status is undefined.
 * When the callback is issued, message->status holds either zero (to
 * indicate complete success) or a negative error code.  After that
 * callback returns, the driver which issued the transfer request may
 * deallocate the associated memory; it's no longer in use by any SPI
 * core or controller driver code.
 *
 * Note that although all messages to a spi_device are handled in
 * FIFO order, messages may go to different devices in other orders.
 * Some device might be higher priority, or have various "hard" access
 * time requirements, for example.
 *
 * On detection of any fault during the transfer, processing of
 * the entire message is aborted, and the device is deselected.
 * Until returning from the associated message completion callback,
 * no other spi_message queued to that device will be processed.
 * (This rule applies equally to all the synchronous transfer calls,
 * which are wrappers around this core asynchronous primitive.)
 */
static inline int
spi_async(struct spi_device *spi, struct spi_message *message)
{
    message->spi = spi;
    return spi->master->transfer(spi, message);
}</span><span style="font-family:Arial, Verdana, sans-serif;"><span style="white-space: normal;font-size:18px;">
</span></span>

        該函數是異步的SPI傳輸函數，可以用於在中端或者某些不能睡眠的上下文場合，當然也可以用於睡眠的場合。

        對於發送給同一個SPI設備的message遵循FIFO的順序，發送給不同的SPI設備的message可以有不同的順序。

        直到從回調函數返回之前，都不能處理該設備的其他spi_message。
        從源代碼可以看到，該函數最後調用了發送給相應設備的相應控制器的transfer函數。
        spi_sync()函數定義在driver/spi/spi.c中，

<span style="font-size:18px;">/**
 * spi_sync - blocking/synchronous SPI data transfers
 * @spi: device with which data will be exchanged
 * @message: describes the data transfers
 * Context: can sleep
 *
 * This call may only be used from a context that may sleep.  The sleep
 * is non-interruptible, and has no timeout.  Low-overhead controller
 * drivers may DMA directly into and out of the message buffers.
 *
 * Note that the SPI device's chip select is active during the message,
 * and then is normally disabled between messages.  Drivers for some
 * frequently-used devices may want to minimize costs of selecting a chip,
 * by leaving it selected in anticipation that the next message will go
 * to the same chip.  (That may increase power usage.)
 *
 * Also, the caller is guaranteeing that the memory associated with the
 * message will not be freed before this call returns.
 *
 * It returns zero on success, else a negative error code.
 */
int spi_sync(struct spi_device *spi, struct spi_message *message)
{
    DECLARE_COMPLETION_ONSTACK(done);
    int status;

    message->complete = spi_complete;
    message->context = &done;
    status = spi_async(spi, message);
    if (status == 0) {
        wait_for_completion(&done);
        status = message->status;
    }
    message->context = NULL;
    return status;
}</span><span style="font-size:18px;">
</span>

        該函數是同步的SPI傳輸函數，只能用於可以睡眠的場合。

7.3 SPI數據傳輸example

        下面是tsc2005進行SPI數據傳輸的例子，

<span style="font-size:18px;">static void tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
{
    u32 tx;
    struct spi_message msg;
    struct spi_transfer xfer = { 0 };
    tx = (TSC2005_REG | reg | TSC2005_REG_PND0 |
           TSC2005_REG_WRITE) << 16;
    tx |= value;

    xfer.tx_buf = &tx;
    xfer.rx_buf = NULL;
    xfer.len = 4;
    xfer.bits_per_word = 24;

    spi_message_init(&msg);
    spi_message_add_tail(&xfer, &msg);
    spi_sync(ts->spi, &msg);
}</span><span style="font-size:18px;">
</span>

        該函數首先定義SPI 傳輸所需的spi_message和spi_transfer數據結構，初始化他們，然後將spi_transfer添加到spi_message的transfer_list鏈表中，最後調用spi_sync()將SPI數據發送出去

2013-05-31 10:43 429人閱讀 評論(0) 收藏 舉報

在移植內核的時候，通常會遇到引腳複用（MUX）的配置問題。在現在的Linux內核中，對於TI的ARM芯片，早已經有了比較通用的MUX配置框架。這對於許多TI的芯片都是通用的，這次看AM335X的代碼順手寫一下分析，以備後用。

一、硬件

    對於許多TI的芯片來說，引腳複用的配置是在Control Module（配置模塊）的寄存器裏配置的，（這個和三星的CPU有點不同，三星的一般在GPIO的寄存器中配置）。所以當你需要配置這些寄存器的時候，請到數據手冊的Control Module的Pad Control Registers查找。

TI的CPU芯片手冊有兩種：
一種是datasheet（DS：數據手冊），較小，只是大概介紹下芯片的結構；
另一種是Technical Reference Manual（TRM:技術參考手冊），較大，詳細介紹芯片的各部分功能原理和寄存器定義。
在開發過程中，這兩個手冊都需要參考，是互補的。

對於AM335X，關於引腳複用的列表及模式號與功能的對應可以在數據手冊中找到：

2 Terminal Description：

2.2 Ball Characteristics

關於引腳複用寄存器定義及各引腳相應寄存器的偏移可以在TRM中找到：

9 Control Module

9.1 Control Module

9.1.3 Functional Description

9.1.3.2 Pad Control Registers （包含引腳複用寄存器定義）

9.1.5 Registers

9.1.5.1 CONTROL_MODULE Registers （包含引腳相應寄存器的偏移）

二、軟件

    由於TI的芯片構架類似，對於Linux內核來說，早就已經爲這個做好了一個軟件上的框架，無論是在啓動的初始化階段還是在系統運行時，都可以通過這個框架提供的接口函數配置芯片的MUX。下面就來簡要的分析一下。

以AM335X爲例，相關代碼位置：arch/arm/mach-omap2

mux.h
mux.c
mux33xx.h
mux33xx.c
board-am335xevm.c

(還有一些用到了：arch/arm/plat-omap/include/plat/omap_hwmod.h）

其中他們的層次關係是：

（1）重要的數據結構

/**
 * struct mux_partition - 包含分區相關信息
 * @name: 當前分區名
 * @flags: 本分區的特定標誌
 * @phys: 物理地址
 * @size: 分區大小
 * @base: ioremap 映射過的虛擬地址
 * @muxmodes: 本分區mux節點鏈表頭
 * @node: 分區鏈表頭
 */
struct omap_mux_partition {
    const char        *name;
    u32            flags;
    u32            phys;
    u32            size;
    void __iomem        *base;
    struct list_head    muxmodes;
    struct list_head    node;
};

    這個數據結構中包含了芯片中幾乎所有定義好的mux的數據，它在mux數據初始化函數omap_mux_init中初始化，並添加到全局 mux_partitions鏈表中（通過node成員）。而其中的muxmodes是所有mux信息節點的鏈表頭，用來鏈接以下數據結構：

/**
 * struct omap_mux_entry - mux信息節點
 * @mux: omap_mux結構體
 * @node: 鏈表節點
 */
struct omap_mux_entry {
    struct omap_mux        mux;
    struct list_head    node;
};

而在以上數據結構中，struct omap_mux是記錄單個mux節點數據的結構體：

/**
 * struct omap_mux - omap mux 寄存器偏移和值的數據
 * @reg_offset:    從Control Module寄存器基地址算起的mux寄存器偏移
 * @gpio:    GPIO 編號
 * @muxnames:    引腳可用的信號模式字符串指針數組
 * @balls:    封裝中可用的引腳
 */
struct omap_mux {
    u16    reg_offset;
    u16    gpio;
#ifdef CONFIG_OMAP_MUX
    char    *muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
    char    *balls[OMAP_MUX_NR_SIDES];
#endif
#endif
};

     而struct mux_partition中muxmodes鏈表及其節點數據的初始化都是在omap_mux_init初始化函數中 （omap_mux_init_list(partition, superset);），而struct omap_mux節點數據中信息是由mux33xx.h和mux33xx.c中提供的。你可以在mux33xx.c中看到一個巨大的struct omap_mux結構體數組初始化代碼，這個代碼一看就明瞭。不同的芯片只需要根據芯片資料修改這個結構體就好了，但是am33xx的這個結構體（當前） 還不完善，gpio的數據還都是0。值得一提的是其中用到了一個宏：

#define _AM33XX_MUXENTRY(M0, g, m0, m1, m2, m3, m4, m5, m6, m7)        \
{                                    \
    .reg_offset    = (AM33XX_CONTROL_PADCONF_##M0##_OFFSET),    \
    .gpio        = (g),                        \
    .muxnames    = { m0, m1, m2, m3, m4, m5, m6, m7 },        \
}

這個宏使得這個結構體數組的初始化變得清晰明瞭。

以 上的數據結構是在系統初始化的時候使用的，在struct omap_mux_partition完成初始化後，omap_mux_init初始化函數最後會根據不同的板子初始化部分mux寄存器 （omap_mux_init_signals(partition, board_mux);），其中牽涉到了以下結構體：

/**
 * struct omap_board_mux - 初始化mux寄存器的數據
 * @reg_offset:    從Control Module寄存器基地址算起的mux寄存器偏移
 * @mux_value:    希望設置的mux寄存器值
 */
struct omap_board_mux {
    u16    reg_offset;
    u16    value;
};

    在最上層的板級初始化文件（board-am335xevm.c）中會定義一個這樣的結構體數組，確定所要初始化的引腳複用寄存器，交由omap_mux_init_signals(partition, board_mux);使用。例如：

#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
    AM33XX_MUX(I2C0_SDA, OMAP_MUX_MODE0 | AM33XX_SLEWCTRL_SLOW |
            AM33XX_INPUT_EN | AM33XX_PIN_OUTPUT),
    AM33XX_MUX(I2C0_SCL, OMAP_MUX_MODE0 | AM33XX_SLEWCTRL_SLOW |
            AM33XX_INPUT_EN | AM33XX_PIN_OUTPUT),
    { .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
#define    board_mux    NULL
#endif

其中用到了一個宏：

/* 如果引腳沒有定義爲輸入，拉動電阻將會被禁用
 * 如果定義爲輸入，所提供的標誌位將確定拉動電阻的配置
 */
#define AM33XX_MUX(mode0, mux_value)                    \
{                                    \
    .reg_offset    = (AM33XX_CONTROL_PADCONF_##mode0##_OFFSET),    \
    .value        = (((mux_value) & AM33XX_INPUT_EN) ? (mux_value)\
                : ((mux_value) | AM33XX_PULL_DISA)),    \
}

注意_AM33XX_MUXENTRY和AM33XX_MUX這兩個宏，前者是用於struct omap_mux的；後者是用於struct omap_board_mux的。

（2）重要的接口函數

/**
 * omap_mux_init - MUX初始化的私有函數，請勿使用
 * 由各板級特定的MUX初始化函數調用
 */
int omap_mux_init(const char *name, u32
flags,
         u32 mux_pbase, u32 mux_size,
         struct omap_mux *superset,
         struct omap_mux *package_subset,
         struct omap_board_mux *board_mux,
         struct omap_ball *package_balls);

這個函數是內部用於初始化struct mux_partition的最總要的函數，但是這個函數並不作爲接口函數使用，而是供各芯片初始化函數“*_mux_init”所使用的。比如AM33XX芯片：

/**
 * am33xx_mux_init() - 用板級特定的設置來初始化MUX系統
 * @board_mux:        板級特定的MUX配置表
 */
int __init am33xx_mux_init(struct omap_board_mux *board_subset)
{
    return omap_mux_init("core", 0, AM33XX_CONTROL_PADCONF_MUX_PBASE,
            AM33XX_CONTROL_PADCONF_MUX_SIZE, am33xx_muxmodes,
            NULL, board_subset, NULL);
}

    有了已經初始化好的struct mux_partition結構體，我們可以利用mux.h提供的許多函數方便的初始化各mux寄存器：

/**
 * omap_mux_init_signal - 根據信號名字符串初始化一個引腳的mux
 * @muxname:        mode0_name.signal_name的格式的Mux名稱
 * @val:        mux寄存器值
 */
int omap_mux_init_signal(const char *muxname, int val);

/**
 * omap_mux_get() - 通過名字返回一個mux分區
 * @name:        mux分區名
 *
 */
struct omap_mux_partition *omap_mux_get(const char *name);

/**
 * omap_mux_read() - 讀取mux寄存器（通過分區結構體指針和寄存器偏移值）
 * @partition:        Mux分區
 * @mux_offset:        mux寄存器偏移
 *
 */
u16 omap_mux_read(struct omap_mux_partition *p, u16 mux_offset);

/**
 * omap_mux_write() - 寫mux寄存器（通過分區結構體指針和寄存器偏移值）
 * @partition:        Mux分區
 * @val:        新的mux寄存器值
 * @mux_offset:        mux寄存器偏移
 *
 * 這個函數僅有在非GPIO信號的動態複用需要
 */
void omap_mux_write(struct omap_mux_partition *p, u16 val, u16
mux_offset);

/**
 * omap_mux_write_array() - 寫mux寄存器陣列
 * @partition:        Mux分區
 * @board_mux:        mux寄存器陣列 （用MAP_MUX_TERMINATOR結尾）
 *
 * 這個函數僅有在非GPIO信號的動態複用需要
 */
void omap_mux_write_array(struct omap_mux_partition *p,
             struct omap_board_mux *board_mux);

在代碼比較完備的芯片中，struct omap_mux中的gpio成員有被初始化過，這樣就可以使用以下接口函數：

/**
 * omap_mux_init_gpio - 根據GPIO編號初始化一個信號引腳
 * @gpio:        GPIO編號
 * @val:        mux寄存器值
 */
int omap_mux_init_gpio(int gpio, int val);

/**
 * omap_mux_get_gpio() - 根據GPIO編號獲取一個mux寄存器值
 * @gpio:        GPIO編號
 *
 */
u16 omap_mux_get_gpio(int gpio);

/**
 * omap_mux_set_gpio() - 根據GPIO編號設定一個mux寄存器值
 * @val:        新的mux寄存器值
 * @gpio:        GPIO編號
 *
 */
void omap_mux_set_gpio(u16 val, int gpio);

     但是am33xx的gpio成員（當前）還都是0，所有這些函數沒法使用。

     此外，在mux.h中還導出了其他的軟件接口和數據結構，這些在am33xx中沒有使用，有需要的時候再看。

     在板級初始化代碼（比如board-am335xevm.c）運行完芯片特定的MUX初始化函數 （am33xx_mux_init(board_mux);）之後，也可以在各子系統初始化時通過上面的接口函數修改配置MUX，比如在am33xx中使 用了自己封裝的一個函數和結構體：

/* 模塊引腳複用結構體 */
struct pinmux_config {
    const char *string_name; /* 信號名格式化字符串，“模式0字符串.目標模式字符串“ */
    int val; /* 其他mux寄存器可選配置值 */
};

/*
* @pin_mux - 單個模塊引腳複用結構體
*            其中定義了本模塊所有引腳複用細節.
*/
static void setup_pin_mux(struct pinmux_config *pin_mux)
{
    int i;

    for (i = 0; pin_mux->string_name != NULL; pin_mux++)
        omap_mux_init_signal(pin_mux->string_name, pin_mux->val);

}

你可以在board-am335xevm.c中看到如下的代碼：

static struct pinmux_config d_can_ia_pin_mux[] = {
    {"uart0_rxd.d_can0_tx", OMAP_MUX_MODE2 | AM33XX_PULL_ENBL},
    {"uart0_txd.d_can0_rx", OMAP_MUX_MODE2 | AM33XX_PIN_INPUT_PULLUP},
    {NULL, 0},
};

......
static void d_can_init(int evm_id, int profile)
{
    switch (evm_id) {
    case IND_AUT_MTR_EVM:
        if ((profile == PROFILE_0) || (profile == PROFILE_1)) {
            setup_pin_mux(d_can_ia_pin_mux);
            /* Instance Zero */
            am33xx_d_can_init(0);
        }
        break;
    case GEN_PURP_EVM:
        if (profile == PROFILE_1) {
            setup_pin_mux(d_can_gp_pin_mux);
            /* Instance One */
            am33xx_d_can_init(1);
        }
        break;
    default:
        break;
    }
}

三、使用注意

     上面初始化過的結構體和接口函數的定義都是帶有"__init"和“__initdata”的，所以這些都只能在內核初始化代碼中使用，一旦系統初始化結束並進入了文件系統，這些定義都會被free。所有它們不能在內核模塊（.ok）中被調用，否則你就等着Oops吧。因爲一個芯片的引腳複用一般是硬件設計的時候定死的，一般不可能在啓動後更改。如果你是在要在模塊中改變引腳複用配置，你只能通過自己ioremap相關寄存器再修改它們來實現