From owner-freebsd-drivers@FreeBSD.ORG Thu Jan 19 18:15:24 2006 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EEC916A41F for ; Thu, 19 Jan 2006 18:15:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A21C43D72 for ; Thu, 19 Jan 2006 18:15:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6468447 for multiple; Thu, 19 Jan 2006 13:16:17 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0JIFCkB063983; Thu, 19 Jan 2006 13:15:14 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-drivers@freebsd.org, Kimberly Davis Date: Thu, 19 Jan 2006 13:00:06 -0500 User-Agent: KMail/1.9.1 References: <20060119155705.13713.qmail@web30004.mail.mud.yahoo.com> In-Reply-To: <20060119155705.13713.qmail@web30004.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601191300.07638.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 11:57:44 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Norbert Koch Subject: Re: Interrupt Handlers and Driver to Driver Communication X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2006 18:15:24 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org