Date: Mon, 16 Oct 2006 17:52:21 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: freebsd-multimedia@freebsd.org, B Briggs <rcbdyndns@bellsouth.net>, rick-freebsd@kiwi-computer.com Subject: Re: New port: pvrxxx for Hauppauge PVR150/500 Message-ID: <Pine.BSF.3.96.1061016173539.15086A-100000@gaia.nimnet.asn.au> In-Reply-To: <20061016073124.GD23971@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Oct 2006, John-Mark Gurney wrote:
> Date: Mon, 16 Oct 2006 00:31:25 -0700
> From: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
> To: usleepless@gmail.com
> Cc: freebsd-multimedia@freebsd.org, B Briggs <rcbdyndns@bellsouth.net>,
> 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 <rick-freebsd@kiwi-computer.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1061016173539.15086A-100000>