Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Re: A question about set 8259A interrupt controller.

OSR_Community_UserOSR_Community_User Member Posts: 110,217
> I'm writing an ATM adapter driver. I want to ask two questions about set
>the 8259A Interrupt controller.
>
> 1.Does ddk supplies the function such as disable_irq to mask the 8259A
>interrupt controller? For example: in the linux, we can simply use the
>disable_irq(3) to disable interrupt 3.

On NT/Win2000 you don't directly deal with physical interrupt levels, you
work in terms of the logical IRQL level. Understanding IRQL's is critical
to understanding how to write NT/Win2000 drivers. To synchronize execution
with interrupt code, you use an appropriate function (like maybe
KeSynchronizeExecution) to raise your IRQL level, which may (or may not)
transparently adjust interrupt controller hardware . Also note that IRQL
levels are processor specific, so even if you raise the IRQL of one
processor, another processor may take an interrupt. This means you may need
a spinlock to protect shared data (KeSynchronizeExecution grabs the
interrupt object spinlock). Also, PCI devices sometimes share interrupt
levels, so physically disabling an interrupt levels might be bad for some
other device

As your device is a network device, and your probably writing an NDIS
driver, there is a special set of OS API's for doing all this (many of
these have names that start with Ndis...).

> 2.If ddk doesn't supply this kind of function, can I write the control
>word by using the WRITE_PORT_UCHAR( )?

Absolutely not, some systems don't use 8259A interrupt controllers (like
most multi processor capable systems ). The physical interrupt controller is owned by the OS, and is
only to be fooled with by it's owner.

- Jan

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi,

    Thank you for your timely answer.

    I've now understood that I could't write control word to the PIC.
    But the problem remains that our network adapter hasn't register which
    can disable/enable itself producing interrupt . Instead, we have to control
    the PIC to let PIC mask/unmask the interrupt.

    So ,how can I disable/enable interrupt in my ISR function? Or does NT
    automatically disable/enable interrupt when the drive enters the ISR
    routine?

    The same problem is with DMA.

    So I wonder whether I should change our hardware design.


    Thank you.




    ÔÚ 00-2-23 12:54:00 ÄúдµÀ£º
    >> I'm writing an ATM adapter driver. I want to ask two questions about set
    >>the 8259A Interrupt controller.
    >>
    >> 1.Does ddk supplies the function such as disable_irq to mask the 8259A
    >>interrupt controller? For example: in the linux, we can simply use the
    >>disable_irq(3) to disable interrupt 3.
    >
    >On NT/Win2000 you don't directly deal with physical interrupt levels, you
    >work in terms of the logical IRQL level. Understanding IRQL's is critical
    >to understanding how to write NT/Win2000 drivers. To synchronize execution
    >with interrupt code, you use an appropriate function (like maybe
    >KeSynchronizeExecution) to raise your IRQL level, which may (or may not)
    >transparently adjust interrupt controller hardware . Also note that IRQL
    >levels are processor specific, so even if you raise the IRQL of one
    >processor, another processor may take an interrupt. This means you may need
    >a spinlock to protect shared data (KeSynchronizeExecution grabs the
    >interrupt object spinlock). Also, PCI devices sometimes share interrupt
    >levels, so physically disabling an interrupt levels might be bad for some
    >other device
    >
    >As your device is a network device, and your probably writing an NDIS
    >driver, there is a special set of OS API's for doing all this (many of
    >these have names that start with Ndis...).
    >

    >- Jan
    >
    >
    >
    >---
    >You are currently subscribed to ntdev as: [email protected]
    >To unsubscribe send a blank email to $subst('Email.Unsub')



    ____________________________
    Free Email/SMTP/POP, http://www.bn3.com, Hosting [email protected]
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Your hardware design needs to change. As soon as you start down a path
    where you need to control a specific pc resource, you now need specific
    support for each motherboard design that's slightly different. It shouldn't
    be much of an issue to disable the interrupt at the adapter, and control
    your DMA correctly.

    > -----Original Message-----
    > From: [email protected]
    > [mailto:[email protected]]On Behalf Of encarta
    > Sent: Thursday, February 24, 2000 9:24 AM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: A question about set 8259A interrupt controller.
    >
    >
    > Hi,
    >
    > Thank you for your timely answer.
    >
    > I've now understood that I could't write control word to the PIC.
    > But the problem remains that our network adapter hasn't register which
    > can disable/enable itself producing interrupt . Instead, we have
    > to control
    > the PIC to let PIC mask/unmask the interrupt.
    >
    > So ,how can I disable/enable interrupt in my ISR function? Or does NT
    > automatically disable/enable interrupt when the drive enters the ISR
    > routine?
    >
    > The same problem is with DMA.
    >
    > So I wonder whether I should change our hardware design.
    >
    >
    > Thank you.
    >
    >
    >
    >
    > ÔÚ 00-2-23 12:54:00 ÄúдµÀ£º
    > >> I'm writing an ATM adapter driver. I want to ask two
    > questions about set
    > >>the 8259A Interrupt controller.
    > >>
    > >> 1.Does ddk supplies the function such as disable_irq to
    > mask the 8259A
    > >>interrupt controller? For example: in the linux, we can
    > simply use the
    > >>disable_irq(3) to disable interrupt 3.
    > >
    > >On NT/Win2000 you don't directly deal with physical interrupt levels, you
    > >work in terms of the logical IRQL level. Understanding IRQL's is critical
    > >to understanding how to write NT/Win2000 drivers. To synchronize
    > execution
    > >with interrupt code, you use an appropriate function (like maybe
    > >KeSynchronizeExecution) to raise your IRQL level, which may (or may not)
    > >transparently adjust interrupt controller hardware . Also note that IRQL
    > >levels are processor specific, so even if you raise the IRQL of one
    > >processor, another processor may take an interrupt. This means
    > you may need
    > >a spinlock to protect shared data (KeSynchronizeExecution grabs the
    > >interrupt object spinlock). Also, PCI devices sometimes share interrupt
    > >levels, so physically disabling an interrupt levels might be bad for some
    > >other device
    > >
    > >As your device is a network device, and your probably writing an NDIS
    > >driver, there is a special set of OS API's for doing all this (many of
    > >these have names that start with Ndis...).
    > >
    >
    > >- Jan
    > >
    > >
    > >
    > >---
    > >You are currently subscribed to ntdev as: [email protected]
    > >To unsubscribe send a blank email to $subst('Email.Unsub')
    >
    >
    >
    > ____________________________
    > Free Email/SMTP/POP, http://www.bn3.com, Hosting [email protected]
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > So ,how can I disable/enable interrupt in my ISR function? Or does NT
    > automatically disable/enable interrupt when the drive enters the ISR
    > routine?

    Yes. Outside the ISR, you can call KeSynchronizeExecution for this.

    Max
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 20 Apr 2020 LIVE ONLINE
Writing WDF Drivers 11 May 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA