Date: Thu, 19 Jan 2006 13:35:55 -0800 (PST) From: Kimberly Davis <kimblydavis@yahoo.com> To: John Baldwin <jhb@freebsd.org>, freebsd-drivers@freebsd.org Cc: Norbert Koch <NKoch@demig.de> Subject: Re: Interrupt Handlers and Driver to Driver Communication Message-ID: <20060119213555.28899.qmail@web30003.mail.mud.yahoo.com> In-Reply-To: <200601191300.07638.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> To: freebsd-drivers@freebsd.org; Kimberly Davis <kimblydavis@yahoo.com> Cc: Norbert Koch <NKoch@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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060119213555.28899.qmail>