tulip driver questions

Hello folks,
I’m trying to parse through the “tulip” ( DEC 21140 ) ethernet chip driver
code on our custom BSP and I have two questions so far. I’m trying to track
down where the interrupt vector for the receive interrupt gets set and I
have traced back to the function nic_create_dev(). I can’t seem to locate
the source for this function. Anyone have a hint?

Secondly, can I add my own little program to hook onto this interrupt, say
just to count received packets, and still have the regular Rx ISR run?

Thanks!
Chris

In article <9s6p85$mtp$1@inn.qnx.com>, bpc2@earthlink.net says…

Hello folks,
I’m trying to parse through the “tulip” ( DEC 21140 ) ethernet chip driver
code on our custom BSP and I have two questions so far. I’m trying to track
down where the interrupt vector for the receive interrupt gets set and I
have traced back to the function nic_create_dev(). I can’t seem to locate
the source for this function. Anyone have a hint?

Secondly, can I add my own little program to hook onto this interrupt, say
just to count received packets, and still have the regular Rx ISR run?

Thanks!
Chris

\

  1. I am not QSSL - so anything they say is more authoritative.

  2. Don’t look in nic_create_dev() it does hardly anything at all - look
    in tulip_RegisterDevice() - that is where the interrupt “vector” gets
    set.

  3. Yes, you should be able to do that - hook into the interrupt - if you
    know what the interrupt number is. BUT that is not enough to be able
    to count received packets! Many, many different things cause an interrupt
    from the tulip card, and you have to poke around in the chip registers to
    find out what caused the interrupt, and what actions need to be taken as
    a result of the interrupt. In the case of a receive or transmit
    interrupt, you then have to poke around in the packet descriptors to
    find out just what happened to the packet. A valid complete receive
    packet is just one possible situation. The driver maintains its own
    count of received packets, and the nicinfo command will report that
    count.


Stephen Munnings
Software Developer
Corman Technologies Inc.

Stephen Munnings <steve@cormantech.com> wrote in message
news:MPG.164f73b77e0fd1819896e0@inn.qnx.com

In article <9s6p85$mtp$> 1@inn.qnx.com> >, > bpc2@earthlink.net > says…
Hello folks,
I’m trying to parse through the “tulip” ( DEC 21140 ) ethernet chip
driver
code on our custom BSP and I have two questions so far. I’m trying to
track
down where the interrupt vector for the receive interrupt gets set and I
have traced back to the function nic_create_dev(). I can’t seem to
locate
the source for this function. Anyone have a hint?

Secondly, can I add my own little program to hook onto this interrupt,
say
just to count received packets, and still have the regular Rx ISR run?

Thanks!
Chris




\

  1. I am not QSSL - so anything they say is more authoritative.

  2. Don’t look in nic_create_dev() it does hardly anything at all - look
    in tulip_RegisterDevice() - that is where the interrupt “vector” gets
    set.

Ok, I saw that, but to be more specific, I’m looking at some of the
arguments to that function, especially “nic” which I think is setup by
nic_create_dev(). I believe that is where the value of the vector is
programmed into the “nic” datastructure. I want that value so that I can
chain onto this interrupt.


  1. Yes, you should be able to do that - hook into the interrupt - if you
    know what the interrupt number is. BUT that is not enough to be able
    to count received packets! Many, many different things cause an interrupt
    snip

Valid, thanks, I was really asking if interrupt service routines could be
“chained”. In this case it looks like no ISR is used they just have the
kernel set an event. Can I still chain in an actual ISR, what about adding
another event?

I’m not actually trying to write a packet counter, but that’s an example
program I may generate along the way.


Stephen Munnings
Software Developer
Corman Technologies Inc.

Thanks!
Chris

bpc2 <bpc2@earthlink.net> wrote:

Ok, I saw that, but to be more specific, I’m looking at some of the
arguments to that function, especially “nic” which I think is setup by
nic_create_dev(). I believe that is where the value of the vector is
programmed into the “nic” datastructure. I want that value so that I can
chain onto this interrupt.

It is actually set in a couple of places. If the command line argument
irq=X is passed to the driver it is set in the parsing code. Otherwise it is
gained from the scan of the PCI bus the driver does on startup. Best
place to chain is just before or after ion_register() is called by the
driver since all the hardware level resources are generally setup by then.

You can use the entry nic->cfg.IRQRegisters[0] to get the interrupt number
you want to use to hook.

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<