Interrupt Handlers and Driver to Driver Communication
kimblydavis at yahoo.com
Tue Jan 24 11:16:31 PST 2006
Over the past few days, I've done more investigation and found out more about the driver's behavior.
By the way, driver one is an edma driver, and driver two is just a simple client driver trying to use the edma. I didn't mention that before because I was trying to remove extraneous detail from the discussion of the problem. I don't think it is really that important in understanding the problem. The client driver does nothing really but exercise the edma driver. It's a nothing driver. It's just there as a test of my edma driver's functionality.
If you remember correctly, the problem is that the edma driver has an api that it makes visible to other drivers who want to call into it. The function "edma_is_complete" returns a status variable to a calling driver. When I call this function from my client driver, I never get the correct status. The problem is the order of events. Before the edma interrupt can complete and set the variable in question, the system seems to halt the interrupt execution, finish the edma_is_complete call, then it finishes the interrupt. This is the reason I get the wrong answer from edma_is_complete every time. I've verified that this is happening by using post codes.
Another interesting development occurred this week. I started calling edma_is_complete from an ioctl in my client driver. This way, it works. I get correct status. I don't understand this. Some sort of weird execution is going on here.
By the way, does FreeBSD have a concept of a bottom half, analogous to generic Linux bottom halves? If so, how do I code it? I can't seem to find information about it or examples.
----- Original Message ----
From: Norbert Koch <NKoch at demig.de>
To: Kimberly Davis <kimblydavis at yahoo.com>
Sent: Monday, January 23, 2006 2:16:52 AM
Subject: RE: Interrupt Handlers and Driver to Driver Communication
> Yes, tried all that...
> nm driver1.ko | grep driver_one_is_complete
> 00003274 T driver_one_is_complete
> nm driver2.ko | grep driver_one_is_complete
> U driver_one_is_complete
> Undefined makes sense because it's not defined in the driver2
> code. It's merely being called.
> A more interesting development occurred yesterday when a
> colleague suggested that I write post codes to the LED on the
> board at different times in the driver so that we could tell how
> long it was lingering over certain executions and see where the
> driver was in its execution of the interrupt handler.
> What I found during that exercise was that the driver interrupt
> handler gets stuck, unable to complete the interrupt handler call
> until driver2's call of the function driver_one_is_complete has
> finished executing. In other words, driver2's activities are
> preventing driver1's activities from finishing. This explains the
> erronenous value that I keep getting with driver_one_is_complete.
> I don't understand this at all. Have you ever encountered this problem?
Not yet. But I only wrote interrupt handlers for FreeBSD 4, where
they don't have some kind of thread context.
So I fear, without knowing more about "driver2's activities", which
obviously are a bit more than just calling driver_one_is_complete(),
nobody will be able to help here.
More information about the freebsd-drivers