Interrupt Handlers and Driver to Driver Communication

[Kimberly Davis]

Yes, certainly.
 
The results of that test are as follows
 
>nm driver1.ko | grep g_status
00004239 B g_status
 
It doesn't make sense to do that for the client_driver (driver2) since the variable isn't defined there or even externed there. I use the API from driver1 (driver_one_is_complete) to find out the value of g_status.
 
Thanks,
KD
----- Original Message ----
From: John Baldwin <jhb at freebsd.org>
To: freebsd-drivers at freebsd.org; Kimberly Davis <kimblydavis at yahoo.com>
Cc: Norbert Koch <NKoch at demig.de>
Sent: Thursday, January 19, 2006 11:00:06 AM
Subject: Re: Interrupt Handlers and Driver to Driver Communication


On Thursday 19 January 2006 10:57, Kimberly Davis wrote:
> Norbert, thanks for responding.
>
> I provide answers to your questions and a little more information below.
>
> In driver 2, I call the function driver_one_is_operation_complete, which is
> part of an API provided by driver 1.
>
> Yes, I have reason to believe that the context becomes active. In other
> words, I believe that the condition CERTAIN_CONDITION_OCCURRED does in fact
> become true at some point. Driver 1 is a dma driver, and I can actually see
> that the driver completes a transaction, which triggers an interrupt. When
> I check the status variable from within driver1 the status does equal 1,
> letting me know that the condition occurred.
>
> if(CERTAIN_CONDITION_OCCURRED)
>     g_status = 1;
>
> My drivers are definitely in different source files, and they are being 
loaded with different invokations of kldload. For example:
> >kldload driver1.o
> >kldload driver2.o
> >kldunload driver2
> >kldunload driver1
>
> Driver2 is dependent on driver1. I use the MODULE_DEPEND macro to ensure
> this dependency. Driver1 is actually composed of two .c files.
>
> Here is the layout for driver1:
>
> dma.c:
> uint32_t g_status
>
> dma_client_api.c:
> extern uint32_t g_status
> The code for driver_one_is_operation_complete is in this file and there is
> a dma_api.h file which contains the function protype.
>
> Here is the file layout for driver2:
> client_driver.c
> In driver2's attach function, I call driver_one_is_operation_complete.
>
> I have tried a volatile delcaration, and it doesn't work. I have checked,
> checked, and re-checked to make certain that I haven't declared the status
> variable twice accidentally.
>
> Also, I should say that I have a uniprocessor system, and the processor is
> not multi-core, so none of the typical questions about hyper-threading, SMP
> syncing issues, or multi-core difficulties seem particularly relevant,
> although I won't rule some sort of phantom issue out. I am using FreeBSD
> 6.0. I've also tried making this variable a part of the softc structure.
> That does not help either.
>
> Obviously I am having some sort of module communication problem, but what?
> I can't seem to nail it down.

Can you provide 'nm driver1.ko | grep g_status' and 'nm driver2.ko | grep 
g_status' output?

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