From owner-freebsd-multimedia Sat Mar 15 14:06:13 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA12222 for multimedia-outgoing; Sat, 15 Mar 1997 14:06:13 -0800 (PST) Received: from hda.hda.com (ip86-max1-fitch.ziplink.net [199.232.245.86]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA12217 for ; Sat, 15 Mar 1997 14:06:09 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id PAA16399; Sat, 15 Mar 1997 15:23:17 -0500 From: Peter Dufault Message-Id: <199703152023.PAA16399@hda.hda.com> Subject: Re: bt848 driver patch In-Reply-To: <199703152116.OAA18410@Ilsa.StevesCafe.com> from Steve Passe at "Mar 15, 97 02:16:09 pm" To: smp@csn.net (Steve Passe) Date: Sat, 15 Mar 1997 15:23:16 -0500 (EST) Cc: dufault@hda.com, hasty@rah.star-gate.com, multimedia@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multimedia@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Can you move the I2C code out of the kernel since it is so lax > > about timing and inherently a slow operation? > > I suspect they can stay in the kernel and that the disable/enable int calls > can be removed. Nothing in the intr routine uses I2C calls, and > as you say the timing is unimportant (who cares if an async INT > stalls it, it will finish eventually) so they should be interruptable. There is no need to turn off interrupts as long as you guarantee nothing else glitches those signals. With it in the kernel you're going to be buzzing away in idle loops locking out other processes. Since we're talking about roughly 50 us per byte we're talking measurable time. But pulling it out of the kernel brings up issues of allocation. I guess the smart and easy thing to do is just pull out the masking. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936