《Linux那些事儿之我是USB》我是U盘(37)迷雾重重的批量传输(六)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/fudan_abc/article/details/7542018

usb_stor_bulk_transfer_sglist()函数有一定的“蛊惑性”,我们前面说过,之所以采用sglist,就是为了提高传输效率。我们更知道,sg的目的就是让一堆不连续的buffers在一次DMA操作都传输出去。其实在USB的故事中,事情并非如此。不过如果你对USB Core里边的行为不关心的话,那就无所谓了。

423行,424行,退出或者断链接,就不要传递数据。

然后429行,usb_sg_init()函数被调用,这个函数来自drivers/usb/core/message.c,也就是说,它是USB核心层提供的函数,干什么用的?初始化sg请求。其第1个参数是struct usb_sg_request结构体的指针。这里我们传递了us->current_sg的地址给它,这里us->current_sg第一次派上用场,所以我们需要隆重介绍一下。

在structus_data中,定义了一个成员structusb_sg_request  current_sg。曾几何时我们见到过current_urb,这里又来了一个current_sg。也许你感觉很困惑。其实可以这样理解,之前我们知道struct urb表示的是一个USB请求,而这里structusb_sg_request实际上表示一个scattergather request,从我们非USB核心层的人来看,这两个结构体的用法是一样的。对于每次urb请求,我们所做的只是申请一个结构体变量或者说申请指针,然后申请内存,第二步就是提交urb,即调用usb_submit_urb(),剩下的事情USB Core就会去帮我们处理了,Linux中的每个模块都给别人服务,也同时享受着别人提供的服务。

你要想跟别人协同工作,只要按照人家提供的函数去调用,把你的指针你的变量传递给别人,其他你根本不用管,事成之后自然会通知你。同样对于sg request,USB Core也实现了这些,我们只需要申请并初始化一个struct usb_sg_request的结构体,然后提交,USB Core自然就知道该怎么处理了。闲话少说,先来看struct usb_sg_request结构体。它来自include/linux/usb.h:

1350 struct usb_sg_request {

1351     int                     status;

1352     size_t                  Bytes;

1353

1354     /*

1355     *members below are private: to usbcore,

1356      * andare not provided for driver access!

1357      */

1358     spinlock_t              lock;

1359

1360     struct usb_device       *dev;

1361     int                     pipe;

1362     structscatterlist      *sg;

1363     int                     nents;

1364

1365    int                     entries;

1366    struct urb              **urbs;

1367

1368    int                     count;

1369     struct completion       complete;

1370 };

整个USB系统都会使用这个数据结构,如果我们希望使用scatter gather方式的话。USB Core已经为我们准备好了数据结构和相应的函数,我们只需要调用即可。一共有3个函数,它们分别是usb_sg_init,usb_sg_wait,usb_sg_cancel。我们要提交一个sg请求,需要做的是先用usb_sg_init来初始化请求,然后usb_sg_wait()正式提交。如果想撤销一个sg请求,那么调用usb_sg_cancel即可。

我们虽说不用仔细去看着三个函数内部是如何实现的,但至少得知道该传递什么参数吧。不妨来仔细看一下usb_sg_init()被调用时传递给它的参数。第1个刚才已经说了,就是sgrequest,第2个,需要告诉它是哪个USB设备要发送或接收数据,我们给它传递的是us->pusb_dev,第3个,是哪个管道,这个没什么好说的,管道是上面一路传下来的。第4个参数,这是专门适用于中断传输的,被传输中断端点的轮询率,对于批量传输,直接忽略,所以我们传递了0。第5个和第6个参数就分别是sg数组和sg数组中元素的个数。第7个参数,length,传递的就是我们希望传输的数据长度。最后一个是slab flag,内存申请相关的一个flag。如果驱动程序处于block I/O路径中应该使用GFP_NOIO,这里SLAB_NOIO实际上是一个宏,实际上就是GFP_NOIO。

为什么用SLAB_NOIO或者GFP_NOIO,请参见前面章节讲到如何调用usb_submit_urb(),理由当时就已经讲过了。这个函数成功返回值为0,否则返回负的错误码。初始化好了之后就可以为us->flags设置US_FLIDX_SG_ACTIVE了,对这个flag陌生吗?还是回去看usb_submit_urb(),当时我们也为urb设置了这么一个flag,US_FLDX_URB_ACTIVE,其实历史总是惊人相似。当初我们对待urb的方式和如今对待sg request的方式几乎一样。所以其实是很好理解的。

对比一下当初调用usb_submit_urb()的代码,就会发现441行到448行这一段我们不会陌生,当年我们提交urb之前就有这么一段,在usb_stor_msg_common()函数中,只不过那时候是urb而不是sg,这两段代码之间何其相似!只是年年岁岁花相似,岁岁年年人不同啊!451行,usb_sg_wait()函数得到调用。它所需要的参数就是sg request的地址,这里传递了us->current_sg的地址给它。这个函数结束,US_FLIDX_SG_ACTIVE这个flag就可以clear掉了。返回值被保存在us->current_sg.status中,然后把它赋给了result。而us->current_sg.Bytes保存了实际传输的长度,把它赋给*act_len,然后返回之前,再来一次调用interpret_urb_result()转换一下结果。

最后,usb_stor_bulk_transfer_sg()函数返回之前还做了一件事,将剩下的长度赋值给了*residual。*residual是形参,实参是&srb->resid。而最终usb_stor_bulk_transfer_sg()返回的值就是interpret_urb_result()翻译过来的值。但是需要明白的一点是,这个函数的返回就意味着Bulk传输中的关键阶段,即数据阶段的结束。剩下一个阶段就是状态阶段了,要传递的是CSW,就像当初传递CBW一样。

回到usb_stor_Bulk_transport()函数中来,判断结果是否为USB_STOR_XFER_ERROR或者USB_STOR_XFER_LONG,前者表示出错,而后者表示设备试图发送的数据比我们需要的数据要多。这种情况可以使用一个fake sense data来向上层汇报,出错了,但是和一般的出错不一样的是告诉上层,这个命令别再重发了。fake_sense刚开始初始化为0,这里设置为1,后面将会用到。目前只需要知道的是,这种情况并不是不存在,实际上USB MassStorage Bulk-only spec里边就定义了这种情况,spec说了对这种情况,下一个阶段还是要照样进行。

最后,解释一点,USB_STOR_XFER_LONG只是我们自己定义的一个宏,实际上是由interpret_urb_result()翻译过来的,真正从USB Core一层传递过来的结果是叫做-EOVERFLOW,这一点在interpret_urb_result函数中能找到对应关系。-EOVERFLOW顾名思义就是溢出。

最后,再解释一点。实际上USB Core这一层做的最人性化的一点就是对urb和对sg的处理了。写代码的人喜欢把数据传输具体化为request,urb和sg都被具体化为request,即请求。而USB Core的能耐就是让写设备驱动的人能够只要申请一个请求,调用USB Core提供的函数进行初始化,然后调用USB Core提供的函数进行提交,这些步骤都是固定的,完全就像使用傻瓜照相机一样,然后进程可以睡眠,或者可以干别的事情,之后USB Core会通知你。你就可以接下来干别的事情了。
展开阅读全文

没有更多推荐了,返回首页