RE: CE 5.0 PCMCIA ISR issue
- From: FoolBlah <foolblah@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 4 Apr 2008 07:57:01 -0700
I have figured out what was going on here. There are multiple confusing
points about the correct way to implement the registry settings so that the
PCMCIA driver uses the real hardware IRQ, none of which is very obvious from
the docs.
First off, the "NoISR" value needs to be populated under the
[HKEY_LOCAL_MACHINE\Drivers\PCCARD\PCMCIA\TEMPLATE\PCMCIA] key. This will
allow the "key" value under the Active key to locate the "NoISR" value
correctly.
The other pieces to this are as follows. The "ClientIrq" value needs to be
set to the user defined SYSINTR value, which should be mapped to the IRQ
defined in the OAL. In addition to this, the SOCK_CAP_ONLY_SYSINTR bit needs
to be set as part of the dwSocketCaps in the SS_SOCKET_INFO struct defined in
pcmsock.cpp. This in itself is confusing in that one would expect the MMD to
inspect the dwSocketIntrCaps value for this bit, but in actuality, it
inspects the general dwSocketCaps, which I personally feel is misleading and
could be considered a bug. If this bit is NOT set correctly (which is easy
to do), no matter how "NoISR" is set, this will cause the installable ISR to
start and "ignore" the real hardware IRQ.
Also, it appears that there is no way to set the PCMCIA\ATADisk ISR thread
priority, is this correct? Understood that only the status/CD ISR thread
priority is set via the "ThreadPriority" value.
Thanks.
"FoolBlah" wrote:
I have been working on a performance issue with our CE 5.0 platform. There.
is a problem I am having with the PCMCIA driver and the ISR (client/data IRQ
not status IRQ or CD IRQ). What is happening is no matter what "NoISR" is
set to under "HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PCC_MAINSTONEII0" the
installable ISR is being loaded. What this does is causes the actual
hardware IRQ from the PCMCIA card to be ignored thus clobbering anything else
that might be occuring throughout the system when an I/O transfer occurs
to/from the PCMCIA card. The goal is to priortize the IRQs via the 270
interrupt controller but I cannot due to the current issue.
The problem appears to be in the CPcmcia::PcmciaCardRequestIRQ() routine
located at \PUBLIC\COMMON\OAK\DRIVERS\PCCARD\PCMCIA\pcmcia.cpp. The CPcmcia
class inherits from CRegistryEdit helper class to deal with registry access.
When CPcmcia is initialized it passes the current active key path loaded in
the registry. The "NoISR" flag in the registry that controls is being looked
at based on the active registry path, which is not correct. This causes in
all cases for the installable ISR to be loaded and run no matter how "NoISR"
is set.
I can force the "NoISR" flag through the debugger, and when doing so the
code behaves as I expect it to. The ATADisk ISR is called when a hardware
IRQ is recieved from the PCMCIA card, does some I/O, waits for another IRQ,
etc. as it should.
Am I placing the "NoISR" in the wrong location, and if so, where does the
flag need to be placed for it to appear in the active registry key when the
driver is loaded? Since the "Active" key is dynamic based on what drivers
are loaded/unloaded I didn't think there was a way to pass it a static value
such as "NoISR".
Any insight is appreciated.
Thanks.
- Follow-Ups:
- Re: CE 5.0 PCMCIA ISR issue
- From: Paul G. Tobey [eMVP]
- Re: CE 5.0 PCMCIA ISR issue
- References:
- CE 5.0 PCMCIA ISR issue
- From: FoolBlah
- CE 5.0 PCMCIA ISR issue
- Prev by Date: Windows CE 5.0 and Windows Server 2008
- Next by Date: Re: BattSuspendTimeout registry
- Previous by thread: CE 5.0 PCMCIA ISR issue
- Next by thread: Re: CE 5.0 PCMCIA ISR issue
- Index(es):
Relevant Pages
|
