On Mon, Dec 27, 1999 at 10:48:16AM -0700, Tim Rightnour wrote:
> According to a few references I found.. the T7250C is nearly identical to the
> DBRI chip found in sparcs.  According to the linux driver, the T7903 is also
> very similar.

The T7250D (for which there is documentation in
http://www.lucent.com/micro/isdn/docs/DS97404.pdf) does not
have a CHI, so I believe, only the ISDN part is similar.

On the other hand, the T7903 seems to have additional DRAM
attached (containing command lists etc) -- on the sparcs,
these lists are located in main memory (AFAIK).

For an audio driver I am thinking of something like this:
dbri? at sbus? slot ? offset ?      # multiple DBRIs possible
audio? at dbri0                     # hardwired to dbri0

audio? should use the CS4215 driver (to be written) in this
case. Is this a reasonable design?

The audio driver has to allocate CHI time slots from
the dbri. Is there a naming convention for functions
providing this kind of resource allocation?

The driver for the CS4215 codec probably is machine/arch independent,
while the attachment to the dbri chip (and the dbri chip itself)
is not -- at least, sbus is required. What do you think of the
following?

sys/dev/sbus/dbri.[ch]
    - autoconfig of the DBRI chip
    - providing resource allocation and access functions for
      attached devices (e.g. audio codec, ISDN)

sys/dev/ic/cs4215{{reg,var}.h,.c}
    - implementing control of the codec (e.g. switching between
      mono / stereo)
    - uses functions supplied by sys/arch/sparc/dev/dbri.[ch]

sys/dev/sbus/audio_dbri.[ch]
    - implemetation of the audio(9) interface

Should some of the files better be placed in sys/arch/sparc/dev?

What changes to the various "*files" files are necessary to
include the new files in kernel builds (I am rather new to
NetBSD kernel programming)?

Any comments are very welcome

    Ingolf
-- 

Ingolf Koch                      Beste Kneipe in Jena-Ost
PGP: 0x7B3B5661  213C 828E 0C92 16B5  05D0 4D5B A324 EC04