Re: USB - wince5.0
- From: "dirw" <dirwdirw.tw@xxxxxxxxxxxx>
- Date: 15 Jun 2006 07:30:54 -0700
Dear Sha,
I also refer WINCE 6.0 Beta and try to fix this issue.
But It still is fail.
Will MicroSoft use QFE to patch this issue ?
BR,
dirwdirw.tw
mars 寫道：
I have modified the part you memtioned in your post, but
it still failed .
The function SetDevicePowerState always return false, so I
have to change the following code
void BulUsbDevice::PowerDown()
{
if (m_CurPowerState == PwrDeviceUnspecified) {
PowerMgr(TRUE) ;
}
}
void BulUsbDevice::PowerUp()
{
m_fResumeOccurred = TRUE;
if (m_CurPowerState == PwrDeviceUnspecified) {
PowerMgr(FALSE) ;
}
}
into =============>>>>>>>>>>>>>>>>>>>>>
void BulUsbDevice::PowerDown()
{
if (m_CurPowerState == PwrDeviceUnspecified) {
PowerMgr(TRUE) ;
}
PowerMgr(TRUE) ;
}
void BulUsbDevice::PowerUp()
{
m_fResumeOccurred = TRUE;
if (m_CurPowerState == PwrDeviceUnspecified) {
PowerMgr(FALSE) ;
}
PowerMgr(FALSE) ;
}
Does SetDevicePowerState will effect suspend/resume ?
Best Wishes
Sha Viswanathan [MSFT] 写道：
Hi guys,
Microsoft is aware of this problem and has implemented a fix that we
released to customers with the Yamazaki Beta. If you have the beta, please
refer to it. By diffing the following files, you should see how to properly
patch the suspend/resume logic:
\public\common\oak\drivers\usbfn\class\serial\usbfndrv.cpp
\public\common\oak\drivers\usbfn\class\serial\usbfndrv.h
\public\csp_pxa27x\oak\pxa27x\inc\bul_usbfn.h (removals only)
\public\csp_pxa27x\oak\pxa27x\usbfn\bul_usbfn.cpp
\public\csp_pxa27x\oak\pxa27x\usbfn\sources (removals only)
\platform\mainstoneiii\src\drivers\usbfn\ms2_usbfn.cpp
In the public usbfn serial driver files some critical section deadlock
issues were fixed. In usbfndrv.h:ClosePipe, we move the 'delete' to after
the critical section. In usbfndrv.cpp:CableDetached, we remove the lock and
unlock completely. With these fixes in place we can handle suspend/resume
differently.
Next the heart of the fix -- the bulverde suspend resume logic (in OOB dir
structure):
Mostly the old suspend/resume logic is removed. The important peices to
remember are
1) in bul_usbfn.cpp, BulUsbDevice::ThreadRun, the variable m_fResumeOcurred
should be or'd with the 2 expressions involving "m_fIsCableAttached", and
nested in the second if(m_fIsCableAttached || m_fResumeOccurred) we should
set m_fResumeOcurred to FALSE (this variable wasn't getting reset).
2) in bul_usbfn.cpp, BulUsbDevice::PowerMgr, the call to CablePowerOff
should be removed completely, as well as anything #defined or controlled by
"ENABLE_SERIAL_AUTO_CONNECTION". At the end of 'else' in PowerMgr, you
should add SetInterruptEvent(m_dwSysIntr) which will cause the interrupt
thread to run and handle the attach we just caused by setting UDE =1.
3) In the platform's ms2_usbfn.cpp: CablePowerOff and CablePowerOn should be
removed. Instead add a virtual function PowerMgr. If(bOff), here we should
execute (" m_pBCRReg->misc_wr2 |= XLLP_BCR_MISCWR2_NUSBC_SC;") then always
call BulUsbDevice::PowerMgr(bOff) to allow the normal logic to take care of
the rest. The software connect here is not required because the IST will
call the _Start function to intiaite reconnect as in #2.
Easy as 1, 2, 3 right? (kidding) If you don't have the Yamazaki beta, and/or
the instructions are not clear to you, please contact me directly for more
information or assistance. I'm currently working on backporting the fix
myself, to verify it works but don't know how quickly I can have it done. To
get a reply, please e-mail with the subject "MainstoneIII OOB ActiveSync
Suspend/Resume".
-Sha Viswanathan
sharathv@xxxxxxxxxxxxxxxxxxxx
This posting is provided "AS IS" with no warranties, and confers no rights.
"mars" <fang.mars@xxxxxxxxxxxxxxx> wrote in message
news:1149057886.989968.282590@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes, I have the same problem
.
- References:
- Re: USB - wince5.0
- From: Sha Viswanathan [MSFT]
- Re: USB - wince5.0
- From: mars
- Re: USB - wince5.0
- Prev by Date: HELP: using net command with XP shared folder. Strange TCP/IP behavior.
- Next by Date: How can I make up a CT69000 driver?
- Previous by thread: Re: USB - wince5.0
- Next by thread: Re: To make WinCE device as USB Mass Storage device
- Index(es):
Relevant Pages
|
Loading
