Re: XScale problem

From: Marco Contenti (marco.contenti_at_nospam.it)
Date: 11/16/04 

Date: Tue, 16 Nov 2004 11:25:58 +0100

Here I'm back.
You shold keep in mind that the under CE the NDIS miniport environment
doesn't work exactly as under NT (2k, XP, etc.). The NDIS wrapper was
provided in CE to make it easier to port existing drivers written for NT
(...).
In particular, don't expect a miniport ISR to run in the context of an
actual interrupt service routine (MS please correct me if I'm wrong).
Miniport drivers ultimately run as part of the device.exe process, while
interrupt management is confined inside the kernel. All that the interrupt
service routine can do is returning a SYSINTR_XXX value to wake up the
corresponding driver IST (in the wrapper), which in turn will call first ISR
and then DPC (this seems reasonable although I couldn't find any doc or
source code from MS to confirm).
So, in WinCE, don't expect multiple or concurrent calls to miniport ISR
followed by a single call to the DPC. Conversely, this may well happen under
NT (...) and miniport drivers written for this environment must be able to
handle it correctly. 

--
Marco Contenti
PROJECT s.a.s. - Windows Embedded Partner
www.projectsas.it
marco DOT contenti AT (see my domain above)
"bytekeeper" <ov@KARO-electronics.de> ha scritto nel messaggio
news:eB2GNwAyEHA.908@TK2MSFTNGP11.phx.gbl...
> Of course You are right. I can add some modifications to my
> drivers (by now they are not designed to handle multiple ints in one
> ISR event) and of course it will work. Thats not a problem,
> at least for drivers where I'm waiting for interrupt event myself,
> but what to do with layered drivers, eg. miniport drivers or
> KITL library. For example using this method KITL
> always hangs with:
>
> !KITLSend(DBGMSG): Reentrant call, hTh:03CF0FBA ...
>
> NDIS wrapper has problems with this to. It does not hang,
> but rises exeptions. Something like: "To early ISR when not waiting for
> ...".
>
> So, it's not really so easy ...
>
> Thanks for Your help
>
> "Marco Contenti" <marco.contenti@nospam.it> wrote in message
> news:OHKWXGAyEHA.260@TK2MSFTNGP11.phx.gbl...
> > I think you need not change any driver, just remove two lines of code in
> the
> > HAL.
> > When the interrupt handler returns SYSINTR_XXX the event on which the
> > corresponding driver is waiting gets signaled. If another edge is
detected
> > in the meantime, this event is signaled again. Then, if the driver is
> > already processing the first interrupt, it will have a second chance to
> > handle the other one, otherwise it must handle both interrupt
conditions.
> > Ususlly driver interrupt threads are already written to handle all
> possible
> > interrupt causes in a single run, or to do nothing if no more processing
> is
> > needed.
> > --
> > Marco Contenti
> > PROJECT s.a.s. - Windows Embedded Partner
> > www.projectsas.it
> > marco DOT contenti AT (see my domain above)
> > "bytekeeper" <ov@KARO-electronics.de> ha scritto nel messaggio
> > news:ehqEEP#xEHA.2212@TK2MSFTNGP15.phx.gbl...
> > > Sorry, my problem explanation was not very clear ...
> > >
> > > I would like to catch GPIO2_XXX edge detect
> > > interrupt occured between OEMInterruptHandler
> > > signaled previous interrupt event and OEMInterruptDone
> > > is called. I don't really need *ALL* edge detect events,
> > > i need only to know that it was *AT LEAST ONE* edge
> > > detect during the OEMInterruptHandler<>OEMInterruptDone
> > > time, and to be protected from the reentrant ISR call
> > > in the same time.
> > >
> > > It works ok for GPIO0 and GPIO1 interrupts because
> > > i can clear edge detect status and mask interrupt in the
> > > OEMInterruptHandler, and then unmask in the
> > > OEMInterruptDone. So, if it was an edge detect event
> > > during interrupt processing time, OEMInterruptHandler
> > > is called again once interrupt is unmasked.
> > > Unfortunately I can't use the same tactics for
> > > GPIO2_XXX edge detect interrupts because they are
> > > all controlled by the single bit in the mask register :(
> > >
> > >
> > > XScale gurus, please help.
> > >
> > > Thanks
> > >
> > >
> >
> >
>
>

Relevant Pages

  • Re: XScale problem
    ... drivers (by now they are not designed to handle multiple ints in one ... ISR event) and of course it will work. ... > When the interrupt handler returns SYSINTR_XXX the event on which the ... >> interrupt occured between OEMInterruptHandler ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Polling loop good here???
    ... The "vertical retrace interrupt" was IRQ 2... ... In today's hardware - as has been mentioned - they've almost certainly ... it...make use of the drivers... ...
    (alt.lang.asm)
  • Re: [RFC] killing the NR_IRQS arrays.
    ... Subject: IRQ API ... interrupt controllers, and knowing hardware designers, they'll ... I believe that there are some common problems with the existing API ... architecture specific drivers now if they feel they would benefit ...
    (Linux-Kernel)
  • Re: hardware interrupt handlers registration and msg-passing ?
    ... through the Minix 3 after just finishing up the understanding of Minix ... to drivers when interrupts occur. ... during interrupt handling when an arbitray interrupt takes place. ... is likely to be the most confusing and hidden-from-me idea. ...
    (comp.os.minix)
  • Re: Any complete sample PCMCIA driver code for WIN 2000 / XP?
    ... >> I also need the same for network (LAN adapter). ... I have found in the "Handling an Interrupt" the following: ... If the interrupt is shared and belongs to the miniport ... the miniport driver should disable interrupts ...
    (microsoft.public.development.device.drivers)