PCI interrupt handler

QNX Newsgroups (Archives) qdn.public.qnx4.devtools
1

Guys,

I’m having some troubles with writing PCI board interrupt handler.

I found PCI device, map its base address in the main routine and have no problem
to work with it (using CA_PCI functions)

However, when I set up interrupt handler for the IRQ line device occupies I
can no longer access board using this base address. Interrupt handler itself runs
fine, I trace it down with ll_debug() insertion and Debugger32. Certainly, base
address seems to be correct inside the handler.

Does anybody know a good source to get sources of working example of PCI driver
with interrupt support (say, for network card)?

Does interrupt processing for PCI device require some extra efforts comparing
to ISA one?

One good example would solve this problem, but I search all QNX site through
and haven’t found one.

Thanks,
Alex

(reply-to: a-l-e-x-@-u-e-i-d-a-q-.-c-o-m ← Please remove dashes!)

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

2

Hi Alex,

While it is not a small example, you might look
at the source to the audiopci soundcard driver in the
ALSA 0.2 source base. It is a QNX4.25 driver that has a
PCI interrupt handler. You can get the source from QUICS
in /usr/free/qnx4/multimedia/ALSA2/ directory.

http://www.qnx.com/cgi-bin/dir_find.cgi?/usr/free/qnx4/multimedia/ALSA2/


Alex Ivchenko <alex-x1@ueidaq.com> wrote:

Guys,

I’m having some troubles with writing PCI board interrupt handler.

I found PCI device, map its base address in the main routine and have no problem
to work with it (using CA_PCI functions)

However, when I set up interrupt handler for the IRQ line device occupies I
can no longer access board using this base address. Interrupt handler itself runs
fine, I trace it down with ll_debug() insertion and Debugger32. Certainly, base
address seems to be correct inside the handler.

Does anybody know a good source to get sources of working example of PCI driver
with interrupt support (say, for network card)?

Does interrupt processing for PCI device require some extra efforts comparing
to ISA one?

One good example would solve this problem, but I search all QNX site through
and haven’t found one.

Thanks,
Alex

(reply-to: a-l-e-x-@-u-e-i-d-a-q-.-c-o-m ← Please remove dashes!)

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

3

Alex Ivchenko <alex-x1@ueidaq.com> wrote:

Guys,

I’m having some troubles with writing PCI board interrupt handler.

I found PCI device, map its base address in the main routine and have no problem
to work with it (using CA_PCI functions)

However, when I set up interrupt handler for the IRQ line device occupies I
can no longer access board using this base address. Interrupt handler itself runs
fine, I trace it down with ll_debug() insertion and Debugger32. Certainly, base
address seems to be correct inside the handler.

Does anybody know a good source to get sources of working example of PCI driver
with interrupt support (say, for network card)?

Have you checked our Knowledge Base? There are some good examples there. I
just did a quick search for PCI Interrupts turned up an entry on writing a PCI
driver for QNX 4.

KB: http://qdn.qnx.com/support/bok/index.html

Also check out the free software section of the QNX website, there are a few
examples there as well.

Free Soft: http://quics.qnx.com/cgi-bin/dir_find.cgi?/usr/free/

Doing a quick search for PCI Interrupt turned up a few examples as well.

Does interrupt processing for PCI device require some extra efforts comparing
to ISA one?

PCI interrupts are level triggered, whereas ISA interrupts are edge triggered.
Also once a PCI devices asserts an interrupt, it will stay asserted until the
interrupt handler has asknowledged the interrupt and got the driver to preform
the required operations to deassert the interrupt (e.g. take data from a buffer
on a card).


Take care!

Erick.


One good example would solve this problem, but I search all QNX site through
and haven’t found one.

Thanks,
Alex



(reply-to: a-l-e-x-@-u-e-i-d-a-q-.-c-o-m ← Please remove dashes!)

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

4

Hi, Eric,

Thanks for your reply!

in PCI sound card driver ISR communicates directly with PIC.
Does QNX take care about PIC or should I program it myself?

#define IMR1 0x21 /* PIC1 Interrupt mask register /
#define IMR2 0xa1 / PIC2 Interrupt mask register */

Also, if I mapped PCI base address in the driver, is this address valid in ISR
handler?

Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

5

Alex Ivchenko <alex@ueidaq.com> wrote:

Hi, Eric,

Thanks for your reply!

in PCI sound card driver ISR communicates directly with PIC.
Does QNX take care about PIC or should I program it myself?

Normally QNX takes complete control of the PIC – you shouldn’t handle
it yourself. It issues an unmask when the first handler is attached for
an irq, issues a mask when the last one is detached, issues the EOI when
the last handler for an irq is called, etc.

Normally, if you want to mask an interrupt, you would call the
qnx_hint_mask() function – the only problem is if you need to
mask an irq in a handler, in that case, you can’t call qnx_hint_mask()
and might have to hit the PIC yourself. I haven’t tested whether it
is safe to use qnx_hint_mask() to unmask the interrupt in this case –
I don’t know whether it maintains a count, and if so, then it won’t
know about your irq-based mask.

Normally, you don’t mask the irq in the handler, you do whatever it takes
to tell your IO card that you have handled the irq – usually this just means
reading a status register on the card. Then, you may do work in the handler,
probably returning a proxy to notify your main task.

#define IMR1 0x21 /* PIC1 Interrupt mask register /
#define IMR2 0xa1 / PIC2 Interrupt mask register */

Also, if I mapped PCI base address in the driver, is this address
valid in ISR handler?

Yes it is valid in the ISR handler – assuming you used mmap() to map
it. (Again, I’m not positive for the qnx_segment_*() calls, but you’ve
probably used mmap().) The ISR can reference the DS of the program that
registered it, and mmap() puts that address range into your DS. Make sure
that a pointer to it is global, so that the ISR can see the pointer.

-David

6

Hi, David,

thanks.

Normally, you don’t mask the irq in the handler, you do whatever it takes
to tell your IO card that you have handled the irq – usually this just means
reading a status register on the card. Then, you may do work in the handler,
probably returning a proxy to notify your main task.
I’m slowly going nuts > :frowning:

It seems that proxy is never received by the process. However, it’s triggered
in ISR, I see it return (proxy) under Debugger32.

For sanity check I took qnx_proxy_attach example from page 739 of Watcom C Library
book. It seems that parent process never receives a proxy triggered by child one.

What are proper compilation flags to compile this example?
What compilation flags beyond -T1 -c -zu -Wc,s should be used to compile interrupt
handler. I’m using Watcom C 10.6

–
Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

7

Alex Ivchenko <aivchenko@ueidaq.com> wrote in message
news:3A393581.6B9E543F@ueidaq.com…

Hi, David,

thanks.

Normally, you don’t mask the irq in the handler, you do whatever it
takes
to tell your IO card that you have handled the irq – usually this just
means
reading a status register on the card. Then, you may do work in the
handler,
probably returning a proxy to notify your main task.
I’m slowly going nuts > :frowning:
It seems that proxy is never received by the process. However, it’s
triggered
in ISR, I see it return (proxy) under Debugger32.

Use something like this for the attach int function call (I had all kinds of
problems when I followed the docs as far as passing the segment)…

qnx_hint_attach(irq, &Handler, my_ds());

The proxy should be global. There are all kinds of little tricks you need
to take care of. Like making sure you don’t trigger your proxy, if you are
executing the proxy code! Clear the interrupt just services.

Where is the proxy getting attached? How are you passing/setting the global
proxy that the interrupt handler needs?

Good luck, be patient!

Augie

For sanity check I took qnx_proxy_attach example from page 739 of Watcom C
Library
book. It seems that parent process never receives a proxy triggered by
child one.

What are proper compilation flags to compile this example?
What compilation flags beyond -T1 -c -zu -Wc,s should be used to compile
interrupt
handler. I’m using Watcom C 10.6

The -T1 for linking and -c -zu -Wc,-s for compiling (does -s vs s make a
difference?).

–
Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

8

“Alex Ivchenko” <aivchenko@ueidaq.com> wrote in message
news:3A393581.6B9E543F@ueidaq.com…

Hi, David,

thanks.

Normally, you don’t mask the irq in the handler, you do whatever it
takes
to tell your IO card that you have handled the irq – usually this just
means
reading a status register on the card. Then, you may do work in the
handler,
probably returning a proxy to notify your main task.
I’m slowly going nuts > :frowning:
It seems that proxy is never received by the process. However, it’s
triggered
in ISR, I see it return (proxy) under Debugger32.

Are you using fork()?

For sanity check I took qnx_proxy_attach example from page 739 of Watcom C
Library
book. It seems that parent process never receives a proxy triggered by
child one.
What are proper compilation flags to compile this example?

I compile the sample: like that “cc sample.c -osample”, the program worked
just fine.
If you can’t get the sample to work either the book and the online doc
differs or
there is a serious problem with your setup.

What compilation flags beyond -T1 -c -zu -Wc,s should be used to compile
interrupt
handler. I’m using Watcom C 10.6

–
Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

9

Hi, Mario,

triggered
in ISR, I see it return (proxy) under Debugger32.

Are you using fork()?
Yep!



I compile the sample: like that “cc sample.c -osample”, the program worked
just fine.
If you can’t get the sample to work either the book and the online doc
differs or there is a serious problem with your setup.
The problem was that I wrote program on my WinNT workstation and then copied it to QNX

using floppy. Some characters were added and compiler get screwed :frowning:
I retyped the same program using QNX’s vedit and everything went fine :slight_smile:

–
Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com

10

–

  • Mario

“People looking to serious, should be looking to Sirius”

“Alex Ivchenko” <aivchenko@ueidaq.com> wrote in message
news:3A3A6233.165D8C29@ueidaq.com…

Hi, Mario,

triggered
in ISR, I see it return (proxy) under Debugger32.

Are you using fork()?
Yep!

Would you happen to have qnx_hint_attch,
qnx_proxy_attach and receive in different process?

I compile the sample: like that “cc sample.c -osample”, the program
worked
just fine.
If you can’t get the sample to work either the book and the online doc
differs or there is a serious problem with your setup.
The problem was that I wrote program on my WinNT workstation and then
copied it to QNX
using floppy. Some characters were added and compiler get screwed > :frowning:
I retyped the same program using QNX’s vedit and everything went fine > :slight_smile:

–
Regards,
Alex

–
Alex Ivchenko, Ph.D.
United Electronic Industries, Inc.
“The High-Performance Alternative ™”

10 Dexter Avenue
Watertown, Massachusetts 02472
Tel: (617) 924-1155 x 222 Fax: (617) 924-1441
http://www.ueidaq.com