Interrupt Handlers and Driver to Driver Communication

[John Baldwin]

On Tuesday 24 January 2006 14:16, Kimberly Davis wrote:
> 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.

When is your client driver calling 'edma_is_complete'?  Also, are you loading 
the drivers during boot or via kldload after the system is running.  Are you 
using any sort of locking (mutex, etc.) to synchronize between your ISR and 
edma_is_complete()?

> 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.

It does have a notion of primary interrupt context which will let your ISR run 
synchronously rather than in an ithread, but for now I would work on getting 
your code to work using ithreads first as it is simpler.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org