(接上一篇) _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调用的关键。 （篇幅太长，请移至下一篇） |
联系客服
