LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

Reply
 
Search this Thread
Old 12-08-2008, 05:49 PM   #1
AustinMarton
Member
 
Registered: May 2007
Location: New Zealand
Distribution: Fedora at home, Ubuntu 10.04 at work
Posts: 88

Rep: Reputation: 16
Question 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.
 
Old 12-09-2008, 04:06 PM   #2
Mara
Moderator
 
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,537

Rep: Reputation: 149Reputation: 149
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
 
Old 12-09-2008, 04:11 PM   #3
Mara
Moderator
 
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,537

Rep: Reputation: 149Reputation: 149
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.
 
  


Reply

Tags
device, driver, ethernet, interrupt, kernel, uclinux


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Device driver for Managed Ethernet Switch IC connected w/ Avalon Bus AustinMarton Linux - General 0 12-07-2008 03:46 PM
Using Linux Ethernet PHY Device Driver Hok Linux - Networking 0 10-08-2008 12:56 AM
getting interrupts form device driver bohemistanbul Linux - Hardware 1 07-30-2007 10:02 PM
iPAQ 10/100 fast Ethernet PCI card device driver philipsyyy Linux - Hardware 4 10-07-2002 05:32 PM


All times are GMT -5. The time now is 02:18 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration