linux驱动基础系列--Linux下Spi接口Wifi驱动分析

前言

  本文纯粹的纸上谈兵,我并未在实际开发过程中遇到需要编写或调试这类驱动的时候,本文仅仅是根据源码分析后的记录!基于内核版本:2.6.35.6 。主要是想对spi接口的wifi驱动框架有一个整体的把控,因此会忽略一些硬件上操作的系统,同时里面涉及到的一些驱动基础,比如数据结构、设备模式也不进行详细说明原理。如果有任何错误地方,请指出,谢谢!

分两步来分析:

第一步:spi接口驱动分析

第二部:基于spi接口的wifi驱动分析

spi接口驱动分析

在cm-x270.c中

static void __init cmx270_init_spi(void)
{
pxa2xx_set_spi_info(2, &cm_x270_spi_info);
spi_register_board_info(ARRAY_AND_SIZE(cm_x270_spi_devices));
} void __init cmx270_init(void)
{
pxa2xx_mfp_config(ARRAY_AND_SIZE(cmx270_pin_config)); #ifdef CONFIG_PM
pxa27x_set_pwrmode(PWRMODE_DEEPSLEEP);
#endif cmx270_init_rtc();
cmx270_init_mmc();
cmx270_init_ohci();
cmx270_init_2700G();
cmx270_init_spi();
}

pxa2xx_set_spi_info实际上是向平台总线注册spi控制器设备。在drivers/spi/pxa2xx_spi.c中有对应的spi控制器的驱动注册:

static int __init pxa2xx_spi_init(void)
{
return platform_driver_probe(&driver, pxa2xx_spi_probe);
}

这样匹配成功后导致pxa2xx_spi_probe的执行,在pxa2xx_spi_probe中,主要是根据cm_x270_spi_info实例化一个spi控制器对象,然后初始化控制器,申请资源,最后调用spi_register_master将该spi控制器实例注册到设备模型上去。里面核心的操作就是scan_boardinfo(master)它会扫描注册的spi设备。这个就是之前函数

spi_register_board_info(ARRAY_AND_SIZE(cm_x270_spi_devices));

调用的结果,它会将cm_x270_spi_devices信息添加到一个全局的链表(中间会wrap一层)。

scan_boardinfo会将全局链表里面总线号和自己匹配的设备都进行注册,即调用spi_new_device,将设备注册到spi总线上去。于是,spi控制器和spi设备(wifi) 都已经准备完毕,剩下的就等spi接口的wifi驱动注册了。

基于spi接口的wifi驱动分析

因为分析的spi接口的wifi驱动是Marvell公司的,所以spi接口的wifi驱动部分看:

linux/drivers/net/wireless/libertas/if_spi.c ,它在

static int __init if_spi_init_module(void)
{
int ret = 0;
lbs_deb_enter(LBS_DEB_SPI);
printk(KERN_INFO "libertas_spi: Libertas SPI driver\n");
ret = spi_register_driver(&libertas_spi_driver);
lbs_deb_leave(LBS_DEB_SPI);
return ret;
}

中调用了spi_register_driver向spi总线注册驱动,这会导致if_spi_probe的调用,它内部会创建一个对象来描述该spi接口的wifi,即struct if_spi_card *card;。同时,也会装载固件到wifi设备中,它是通过if_spi_prog_helper_firmwareif_spi_prog_main_firmware实现的。

  关于固件的主要作用

   Firmware是在Wi-Fi设备硬件中执行的一段程序,系统上电后由WLAN驱动将其下载到Wi-Fi模块中,实现Wi-Fi硬件接口控制、数据缓冲、802.11与802.3帧类型转换、802.1l MAC层管理、WLAN MAC中断管理以及硬件控制等功能。发送数据时,Host驱动程序将从上层接收到的标准802.3帧发送给Firmware,Firmware将收到的数据帧转换成802.11帧,再通过无线连接将数据传输出去;接收数据时,Firmware将接收到的所有802.11帧转换成802.3帧后,通过SPI口发送给Host驱动。由此可见,Wi-Fi无线网卡设备在Linux中是被当作普通的以太网设备对待的,在Wi-Fi驱动程序中无需实现802.11帧与802.3帧之间的类型转换。

然后会将刚申请并初始化完成的card注册到libertas中,即调用:lbs_add_card(card, &spi->dev); lbs_add_card的主要作用是让card成为net device功能,它调用alloc_netdev申请了一个网络设备,需要注意的是赋予了网络子系统将来会用到的操作集lbs_netdev_ops

static const struct net_device_ops lbs_netdev_ops = {
.ndo_open = lbs_dev_open,
.ndo_stop = lbs_eth_stop,
.ndo_start_xmit = lbs_hard_start_xmit,
.ndo_set_mac_address = lbs_set_mac_address,
.ndo_tx_timeout = lbs_tx_timeout,
.ndo_set_multicast_list = lbs_set_multicast_list,
.ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};

同时注意下面的调用,后面会基于这些通信:

        init_waitqueue_head(&priv->waitq);
priv->main_thread = kthread_run(lbs_thread, dev, "lbs_main");
if (IS_ERR(priv->main_thread)) {
lbs_deb_thread("Error creating main thread.\n");
goto err_ndev;
} priv->work_thread = create_singlethread_workqueue("lbs_worker");
INIT_DELAYED_WORK(&priv->assoc_work, lbs_association_worker);
INIT_DELAYED_WORK(&priv->scan_work, lbs_scan_worker);
INIT_WORK(&priv->mcast_work, lbs_set_mcast_worker);

接着if_spi_probe里面会调用:

 priv->hw_host_to_card = if_spi_host_to_card;

它会在Libertas层收到网络子系统数据的时候调用

 card->spi_thread = kthread_run(lbs_spi_thread, card, "lbs_spi_thread");

负责数据包的接收和命令的响应处理线程

 err = request_irq(spi->irq, if_spi_host_interrupt,
IRQF_TRIGGER_FALLING, "libertas_spi", card);

用于处理spi接口网卡上的中断

 err = lbs_start_card(priv);

它的调用链是

lbs_cfg_register -> wiphy_register ->register_netdev

,这样之后网络子系统就能够使用该网卡驱动了。

下面分几个情景分析上面这些核心函数的作用

情景分析

情景1:上层网络子系统有数据发送

lbs_hard_start_xmit函数会被调用,这个函数属于上文说过的网络子系统将来会用到的操作集lbs_netdev_opslbs_hard_start_xmit首先将数据包拷贝到自己的buf里面,然后唤醒其他线程然后退出,priv是libertas层维护的对象,是在上文中lbs_add_card的时候分配的。

调用层次

lbs_add_card -> lbs_cfg_alloc -> wdev->wiphy = wiphy_new(&lbs_cfg80211_ops, sizeof(struct lbs_private)); , 属于wdev额外分配的一段内存,可以通过priv = wdev_priv(wdev);获取。 wake_up(&priv->waitq);实际唤醒的是lbs_thread线程,由于是发送数据包,会调用lbs_execute_next_command,接着会导致lbs_submit_command -> priv->hw_host_to_card

priv->hw_host_to_card是上文中说过的if_spi_host_to_card,因为是通过spi接口发送数据,所以调用spi驱动probe时注册的函数是理所当然的。

if_spi_host_to_card最终会导致spi控制器实例的master->transfer会被调用,它是在第一步中的pxa2xx_spi_probe里注册master->transfer = transfer;,transfer实际上就是最终的硬件操作了,但它实际上也是异步的,它呼叫一个工作线程去完成这些任务

if (drv_data->run == QUEUE_RUNNING && !drv_data->busy)
queue_work(drv_data->workqueue, &drv_data->pump_messages);

drv_data->workqueue也是在pxa2xx_spi_probe完成的:

init_queue
-> tasklet_init(&drv_data->pump_transfers,
pump_transfers, (unsigned long)drv_data);
-> INIT_WORK(&drv_data->pump_messages, pump_messages);
-> drv_data->workqueue = create_singlethread_workqueue(
dev_name(drv_data->master->dev.parent));

最终pump_messages会被调用. 它最后会导致pump_transfers来完成硬件数据传送。

这个过程确实非常绕,下面分析下为什么需要这些过程:

首先是lbs_thread,它的存在不仅仅是处理数据的发送,同时还要处理设备返回的事件和命令的响应。上层数据包发送的时候,我们应该尽可能快的完成处理并返回,不然网络子系统就会延迟了,但这并不是最主要的, 将一类事件异步统一到一个线程里面处理也是有很多优势的。然后是priv->hw_host_to_card的回调问题,网卡驱动的libertas层实际上是和具体的硬件接口分离的,不然它还得关心是spi接口、sdio接口、或者是usb接口的wifi等等,所以采用回调的方式,让具体的接口处理部分注册回调函数。

if_spi_host_to_card调用spi控制器实例的master->transfer很容易理解,具体的数据传送当然的操作控制器。

对于控制器里面的实现,即master->transfe的transfer 它采用工作线程的方式来统一处理所有的发送数据包,这样就可以和lbs_thread实现异步,各种更容易处理各自的队列等。

情景二:设备接收到数据

Spi接口的wifi有数据过来的时候,会通过spi中断,所以理所当然的进入注册的spi irq的中断处理函数if_spi_host_interrupt,它的实现很简单,异步处理,自己本身不进行任何处理(毕竟在中断,处理spi有可能sleep,那就玩玩了,呵呵),即调用up(&card->spi_ready)唤醒其他线程来做事情。

睡在这信号量上的线程是:lbs_spi_thread,这个是上文第一步中的if_spi_probe中创建的,这个好理解啦。它的处理函数lbs_spi_thread,读状态寄存器,根据状态来决定是什么事件。

/* Read the host interrupt status register to see what we
* can do. */
err = spu_read_u16(card, IF_SPI_HOST_INT_STATUS_REG,
&hiStatus);

数据的处理就在:

 if (hiStatus & IF_SPI_HIST_RX_UPLOAD_RDY)
err = if_spi_c2h_data(card);
if (err)
goto err;

if_spi_c2h_data的处理和其他网卡的处理类似,分配sk_buff 然后读到分配的buff里面(读可以直接读,也可以用dma),然后调用lbs_process_rxed_packet经过一些处理调用netif_rx来传给网络子系统。

情景三:命令的响应处理

和情景二类似,都是在lbs_spi_thread中,不过是进入了另一个判断里面:

if (hiStatus & IF_SPI_HIST_CMD_UPLOAD_RDY)
err = if_spi_c2h_cmd(card);
if (err)
goto err;

if_spi_c2h_cmd命令的响应当然没必要让网络子系统知道,因为对于网络子系统,spi wifi就是一个网络设备而已,不知道这些具体的命令的含义。我们这个理所当然的是让libertas层的lbs_thread线程处理,这个上文 情景1:上层网络子系统有数据发送 已经有过分析。它会进入到

if (priv->resp_len[resp_idx]) {
spin_unlock_irq(&priv->driver_lock);
lbs_process_command_response(priv,
priv->resp_buf[resp_idx],
priv->resp_len[resp_idx]);
spin_lock_irq(&priv->driver_lock);
priv->resp_len[resp_idx] = 0;
}

最终调用lbs_process_command_response来处理命令的响应。

完!

2014年5月

上一篇:Linux驱动中的platform总线分析


下一篇:手把手教你从零实现Linux misc设备驱动一(基于友善之臂4412开发板)