Interrupts and precedence in an Ethernet driver TX/RX? Tasklets? 2 drivers 1 device?
 

Hi there,

We are writing an Ethernet driver for a Switch IC for uClinux (2.6 kernel) running on a NIOS2 processor. I am having difficulty understanding how the kernel will deal with the interrupts. I have been referring to both 'Understanding the Linux Kernel' and 'Linux Device Drivers' (O'Reilly), but I am not sure if I am applying it correctly to this situation.

We have split the task in to two drivers:
- a char driver to deal with switch settings and rx/tx of control frames (containing statistical info etc.).
- a net driver that is in charge of rx/tx of Ethernet frames.
(I am not sure if this is the optimal solution, as combining the driver in to one seems a lot simpler to me, so any opinions on this method would be appreciated.)

• Firstly I would like to clarify how the kernel swaps between events. If for example the transmit function is partially complete (maybe part way through writing to an indirectly adressed register), and an interrupt is received, so the execution jumps to the irqhandler, which in turn calls the rx function. Does this mean that if the rx function accesses the registers and changes the address, that the tx function will read the wrong values when it continues execution?
  
  I am using the function
  Code:

  ---

  spin_lock_irqsave(&db->lock, flags);

  ---

  at the start of the transmit function. Does this mean that an interrupt will have to wait till it is unlocked?
  
  Would either of the above answers be different if the transmit and receive functions were in different drivers?
  
• Secondly, How does it work when two device drivers attempt to access the same device? Will one be locked out or have to queue for it? or will the both write/read to the address and data lines causing a disaster? (The switch is connected to the CPU via an Avalon MM bus.)
  
• Lastly, from what I have been reading, it seems like the best way for me to do the reception of Ethernet frames would be to begin the process in the interrupt handler, and then have a tasklet which is queued up to finish it off at a later state. But the drivers we are basing ours on all just complete the entire transmission and reception in single functions without any sort of 'bottom half' split. Infact I can only find 1 driver in the uClinux kernel which does do this.
  Would just doing the entire job in the interrupt handler greatly impede performance/operation of the switch?

Thank you very much for taking the time to read my post, hopefully it isn't too device specific, ANY comments are welcomed!

Austin.

A number of notes (from the ones easier to answer):
Q2 It's your task to write your drivers in such a way that if they access the same hardware, they do it without making mess in the registers. In short words: you need to synchronize them. Mutex, spinlock, interrupts off - there are different solutions for different cases.
Q3 For most drivers it doesn't make difference - they don't process much data. Ethernet driver is different. Especially under a high load you have (high) megabits per second to deal with. If you try to perform everything in an interrupt, with interrupts off, you may get a lagging system. It is important to be fast enough so you can get the packets out of the hardware buffers, without overflows and such. Processing after that may have lower priority, because not big harm will be done if the packet stays in one of the queues for some more time. Or, in the worst case, you may simply drop part of a queue if it's too long :)

Q1 In a case of wrong synchronization, yes. Usually, however, the register do not have many common points - but you should refer to the documentation and be very careful. It's hard to imagine to go without a spinlock or two, however. And yes, if you lock interrupts for too long, it will have to wait and it is possible that you may get an overflow if the hardware buffer gets full. Make controls sections as short as possible, in both rx and tx. And try to find out what your worst case is.

If I were you, I'd go for one driver. Less points to synchronize, what means less bugs.