From owner-freebsd-multimedia@FreeBSD.ORG Mon Oct 16 07:52:43 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6DE616A40F for ; Mon, 16 Oct 2006 07:52:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id D73FA43D53 for ; Mon, 16 Oct 2006 07:52:41 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id RAA20237; Mon, 16 Oct 2006 17:52:22 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 16 Oct 2006 17:52:21 +1000 (EST) From: Ian Smith To: John-Mark Gurney In-Reply-To: <20061016073124.GD23971@funkthat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-multimedia@freebsd.org, B Briggs , rick-freebsd@kiwi-computer.com Subject: Re: New port: pvrxxx for Hauppauge PVR150/500 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 07:52:43 -0000 On Mon, 16 Oct 2006, John-Mark Gurney wrote: > Date: Mon, 16 Oct 2006 00:31:25 -0700 > From: John-Mark Gurney > To: usleepless@gmail.com > Cc: freebsd-multimedia@freebsd.org, B Briggs , > rick-freebsd@kiwi-computer.com > Subject: Re: New port: pvrxxx for Hauppauge PVR150/500 > > usleepless@gmail.com wrote this message on Mon, Oct 16, 2006 at 08:40 +0200: > > On 10/16/06, Rick C. Petty wrote: > > >I think it's timing-critical, although an I2C bus has clock and data lines, > > >so I can't see any reason the kernel needs to block during the download. > > >Feel free (anyone) to look into the iic code and pull it out from under > > >GIANT. > > > > will that help? reason i ask is because with the i2c, the cpu is > > responsible for every bit-switch/line-switch in the protocol. so > > through the pci-interface, it tells the card to pull the line up, you > > wait a very short time, and tell it to pull the i2c-line down. etc... > > It depends upon the interface... Some things like the bktr have > the ability to drive the i2c bus in hardware.. only if you use the > iicbb (iic bit bang) driver, does the software do all the work... > (though it appears that bktr uses iicbb instead of the hardware).. Even bit-banging, I expect that it should be able to service interrupts between bytes - though not between bits, obviously - at least while transmitting. I have very little experience with iic, but am currently boning up on it for a board using two Atmel AVR processors connected by iic via optocouplers. Even long delays between transmitted bytes should be no problem unless the receiver has some unusual? timing requirements. I've had a few quick forays through iicbb and all in /sys/dev/iicbus but admit to not making much sense of it compared to the simple AVR-asm code I've been studying, especially regarding the various bus layers, but it does appear that iicbb is pretty long in the tooth ('98?) Cheers, Ian