(接
上一篇)
_USBPORT_MapTransfer是个比较复杂的函数了,他涉及到transfer的切割、sgList结构的填写,少安毋躁。。。哈哈
struct SG_LIST{ ULONG Flags; PVOID CurrentVa; PVOID MappedSysAddress; ULONG EntriesCount; SG_ENTRY Entries[1]; // var size};struct SG_ENTRY{ ULARGE_INTEGER PhysicalAddr; PVOID VirtualAddr; ULONG Length; ULONG Offset; ULONG field_14; // unknown};_USBPORT_MapTransfer(pFdo,pIrp,pMapRegisterBase,pTransfer){ pFdoExt->DoMapping = FALSE // 1. build sgList ULONG ulMappedLength = pUrb->TransferBufferLength do { IoMapTransfer(...&ulMappedLength..); add physical:virtual to sgList ulMappedLength = pUrb->TransferBufferLength - ulMappedLength } while(ulMappedLength != 0); // 2. split transfer if this is an iso transfer init some field for iso transfer only LIST_ENTRY listHeader; call _USBPORT_SplitTransfer(..pTransfer,&listHeader); while(listHeader is not empty) { get transfer from list header insert to endpoint\'s ActiveTransfer } // 3. endpoint worker call _USBPORT_CoreEndpointWorker if return != 0 call _USBPORT_InvalidateEndpoint}看到这里我想你也能大致CoreEndpointWorker跟InvalidateEndpoint的大致作用,很明显是用来处理active transfer list的。先不管他,来看split:
USBPORT_SplitTransfer(pFdoExt,pEndpoint,pTransfer,pListHead){ init pTransfer->ChildTransferListHead if(pTransfer->TransferBufferLength <= pEndpoint->MaxTransferLength) insert pTransfer to pListHead else { ASSERT(pTransfer->Type == interrupt || pTransfer->Type == bulk) call _USBPORT_SplitBulkInterruptTransfer } }很简单的逻辑:只有在transfer length 大于endpoint的最大传输大小,并且是interrupt或者bulk的时候,才split。最多传输长度并不是MaxPacketSize,这个长度要大得多。
_USBPORT_SplitBulkInterruptTransfer(pFdo,pEndpoint,pTransfer,pListHead){ ULONG ulChildrenCount = pEndpoint->MaxTransferLen / pTransfer->TransferBufferLength ExAllocatePool(sizeof(TRANSFER) * ulChildrenCount) copy from pTransfer to all the new allocated structs reinit all the children transfer\'s list entry ULONG ulLeftTransferLen = pTransfer->TransferBufferLength pChildTransfer = FirstChildTransfer pOrgSgList = &pTransfer->sgList curSgEntryIndex = 0 curOffsetInEntry = 0 OffsetInTotalBuffer = 0 while(leftTransferLen != 0) { call _USBPORT_MakeSplitTransfer( pFdo, pOrgSgList, pChildTransfer, MaxTransferLength, MaxPacketLength, &curSgEntryIndex, &curOffsetInEntry, leftTransferLength, OffsetInTotalBuffer ) leftTransferLen = return value link pChildTransfer to pListHead OffsetInTotalBuffer += pChildTransfer->TransferBufferLength pChildTransfer = NextChildTransfer }}这个过程有些复杂。简单的讲,这个函数首先计算需要多少个children transfer,然后分配这么多个结构,然后把原来结构的内容copy到新的每个结构里面,但是那些list必须要重新初始化成正确的值,不能指向原来的transfer。然后调用一个辅助函数切割原来transfer的sgList,每个小的transfer的大小最多是 pEndpoint->MaxTransfer 这么大。
sgList是由一个一个的sgEntry组成的,这些sgEntry的长度却未必就是pEndpoint->MaxTransfer 这么大,所以必须由两变量来表示当前处理的是哪个entry,以及当前处理到了这个entry的哪个offset。也就是上面 curSgEntryIndex 和 curOffsetInEntry 的作用,USBPORT_MakeSplitTransfer辅助函数会修改这两个值。
最后注意,原来那个被切割的transfer并没有进入pListHeader,当然也就没有进入Endpoint的ActiveTransfer。
USBPORT_MakeSplitTransfer( pFdo, pOrgSgList, pChildTransfer, MaxTransferLen, MaxPacketLen, pCurEntryIndex, pCurOffsetInEntry, LeftTransferLen, OffsetInTotalBuffer){ ASSERT(MaxTransferLen % MaxPacketLen == 0) length = MaxTransferLen left = pOrgSgList->sgEntry[*pCurEntryIndex].Length - *pCurOffsetInEntry pChildTransfer->sgList.Count = 0 i = 0 while(length > left) { pChildTransfer->sgList.Count ++ pChildTransfer->sgList.sgEntry[ i ]. Length = left pChildTransfer->sgList.sgEntry[ i ].VirtualAddr = pOrgSgList->sgEntry[*pCurEntryIndex].VirtualAddr + *pCurOffsetInEntry pChildTransfer->sgList.sgEntry[ i ].PhysicalAddr = pOrgSgList->sgEntry[*pCurEntryIndex].PhysicalAddr + *pCurOffsetInEntry i ++ *pCurEntryIndex ++ *pCurOffsetInEntry = 0 LeftTransferLen -= left length -= left left = pOrgSgList->sgEntry[*pCurEntryIndex].Length } if(length) { pChildTransfer->sgList.Count ++ pChildTransfer->sgList.sgEntry[ i ].Length = length pChildTransfer->sgList.sgEntry[ i ].VirtualAddr = pOrgSgList->sgEntry[*pCurEntryIndex].VirtualAddr + *pCurOffsetInEntry; pChildTransfer->sgList.sgEntry[ i ].PhysicalAddr = pOrgSgList->sgEntry[*pCurEntryIndex].PhysicalAddr + *pCurOffsetInEntry; *pCurOffsetInEntry += length if(*pCurOffsetInEntry == pOrgSgList->sgEntry[*pCurEntryIndex].Length) { *pCurOffsetInEntry = 0 *pCurEntryIndex ++ } } return LeftTransferLen - length}逻辑很简单,按照MaxTransferLen划分切割就行了。
接下来就是要真正处理active transfer的部分了:
_USBPORT_CoreEndpointWorker(pEndpoint,bRecursion){ if(!bRecursion) { if(pEndpoint->Busy) return 1; else pEndpoint->Busy = 1 } call _USBPORT_GetEndpointState(pEndpoint) state = return value if(state == closed) { pEndpoint->Busy = 0 return 0; } call _USBPORT_PollEndpoint(pEndpoint) call _USBPORT_GetEndpointState(pEndpoint) state = return value if(state == removed) { pEndpoint->CurrentState = close pEndpoint->NextState = close insert the endpoint to fdo\'s ClosedEndpointListHead pEndpoint->Busy = 0 return 0 } if(pEndpoint->ActiveTransfer is empty && pEndpoint->PendingTransfer is empty && pEndpoint->CancelTransfer is empty) { pEndpoint->Busy = 0 call _USBPORT_FlushAbortList(pEndpoint) return 0 } call _USBPORT_GetEndpointState(pEndpoint) state = return value if(state != pEndpoint->NextState) { pEndpoint->Busy = 0 return 1 } call pEndpoint->WorkRoutine(pEndpoint) call _USBPORT_FlushAbortList(pEndpoint) pEndpoint->Busy = 0 return 0;}眼见函数就要分析完了,这个家伙马上又引出来若干个函数。。哈哈
其中_USBPORT_FlushAbortList函数在讲到cancel的时候再说,他其实是一个无关紧要的函数。
而_USBPORT_PollEndpoint函数则是调用miniport对应的Poll函数,在这个函数里面,miniport driver总是检查自己的transfer有没有完成了的,如果有就告诉usbport自己完成了某个transfer。
至于_USBPORT_GetEndpointState更是简单,如果pEndpoint->CurrentState == pEndpoint->NextState,则返回CurrentState,否则返回一个特殊的值 ENDPOINT_STATE_TRANSITION,这个值从来不会被设置到CurrentState 跟 NextState成员上面。
至于这个state的用法这里先大致的说说,state表征了endpoint的当前状态,能够设置的值有active, pause, remove, close,后两种是在特别的情况下才设置的。当你关闭一个endpoint的时候 (select configuration却填一个0的config desc),endpoint进入remove状态,上面已经看到他马上就转换成了close状态而进入了fdo的closed enpoint list,作lazy close。而active状态就是正常状态,在这个状态下,endpoint把自己的active list里面的transfer一一提交给miniport driver。而pause的状态是为了处理cancel跟abort的情况的。如果active list里面的transfer有某个被标记成了canceled或者aborted.endpoint就从active状态进入pause状态。进入 pause状态以后一一完成那些标记成canceled和aborted的transfer,直到全部都处理完了,就转入active状态。
那上面这些操作都是由谁来完成的呢?当然不用说也是pEndpoint->WorkRoutine要作的事情了。
当然,状态的转换并不是这么简单的事情。一个最主要的原因是要同步endpoint的FrameNumber32Bit成员到当前usb host controller的Frame Number,这个主要是用于Iso传输的,所以状态转换的过程是个迂回的。
endpoint 首先进入fdo的state change list,然后fdo让miniport driver在下一个start of frame的时候引发一个中断,在isr的dpc里面同步endpoint的Frame Number,然后把endpoint从state change list里面取出来,这样endpoint才算是进入了新的状态,也就是让endpoint的CurrentState跟NextState相同。
然后要注意的是,这个函数如果返回值是1的话,紧接着调用的就是_USBPORT_InvalidateEndpoint函数。这个函数告诉一个辅助线程 (通过设置一个Event),调用一次_USBPORT_CoreEndpointWorker。miniport driver也会在比如某个传输完成的时候调用这个函数来排队CoreEndpointWorker的调用,使得usbport能继续向其提交新的传输,而不是停下来。
上面这段话是什么意思呢?看这个流程:进入pending -> flush pending -> 进入map ->flush map->MapTransfer进入 active->CoreWorker 提交一些但不是全部的transfer给硬件。
这里就层层返回了..并没有连续的提交。那要提交下一个怎么办呢?必须要再次进入CoreWorker才可以,这就是通过InvalidateEndpoint函数来完成的。
Invalidate 这个函数把你要Invalidate的Endpoint收集到一个list里面链接到fdo的AttendListHead上,然后唤醒work thread。work thread从fdo的AttendListHead上一一取出每个endpoint,然后调用CoreWorker,如果返回还是1,则保存到另外一个 list上面。当第一遍循环完了,再把那些还是返回1的endpoint重新链接到fdo的AttendListHead上面,再次排队下一个 CoreWorker调用,也就是再次设置Event,而不是直接循环再调用CoreWorker。
希望能明白这种排队poll调用的机制。记住一点:
transfer的处理是要通过调用CoreWorker才会传递给miniport然后传递给硬件的,InvalidateEndpoint正是引发一次CoreWorker调用的关键。(篇幅太长,请移至
下一篇)