From owner-freebsd-multimedia  Tue Mar 25 19:49:46 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id TAA11503
          for multimedia-outgoing; Tue, 25 Mar 1997 19:49:46 -0800 (PST)
Received: from Ilsa.StevesCafe.com (sc-gw.StevesCafe.com [205.168.119.191])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA11495
          for <multimedia@FreeBSD.ORG>; Tue, 25 Mar 1997 19:49:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.7.5/8.6.12) with SMTP id UAA03308; Tue, 25 Mar 1997 20:49:30 -0700 (MST)
Message-Id: <199703260349.UAA03308@Ilsa.StevesCafe.com>
X-Authentication-Warning: Ilsa.StevesCafe.com: Host localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: Richard Tobin <richard@cogsci.ed.ac.uk>
cc: Amancio Hasty <hasty@rah.star-gate.com>, multimedia@FreeBSD.ORG
Subject: Re: newest bt848 driver 
In-reply-to: Your message of "Wed, 26 Mar 1997 03:38:04 GMT."
             <26337.199703260338@pitcairn.cogsci.ed.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 25 Mar 1997 20:49:30 -0700
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

> > Another approach is to  probe all i2c addresses from 0xc1, 0xc3, ... 0xcf.
> 
> I tried this, and c3 worked.  TSA552x_RADDR is #defined to be c3,
> and the comment describes it as a "guaranteed address" - what dooes
> that mean (and if it's guaranteed, why don't all the cards use it)?

generically the i2c chips are programmable for different chips to allow
more than 1 in a circuit.  why any particular address is used in a
particular card is a design decision based on various factors.  we depend
on them being at different addresses to be able to identify the card.
is c3 the ONLY address that spoke out?

---
> Anyway, if I use c3, I get a picture!  Only B&W though so far.  When I
> tried the cable channels I got nothing and then it completely hung the
> machine.  I'll try some more experiments tomorrow.

do you have another machine around to 'ping' it? I have seen a 'hang'
here, (twice in several weeks of heavy usage).  in my case you can still
ping the machine over the network, which suggests that an ioctl has hung
hard, but INTs are still active.  I think I know how it could happen, one
of those race conditions... am thinking about how to deal with it.
--
Steve Passe	| powered by
smp@csn.net	|            Symmetric MultiProcessor FreeBSD