Subject: Re: Private bus spaces
To: Eivind Eklund <eivind@yes.no>
From: Ignatios Souvatzis <ignatios@theory.cs.uni-bonn.de>
List: tech-kern
Date: 09/28/1998 12:59:25
On Sun, Sep 27, 1998 at 09:13:54PM +0200, Eivind Eklund wrote:
> I'm trying to properly bus-space the Brooktree848 driver from FreeBSD,
> both to have a clean interface in FreeBSD and in the hope that NetBSD,
> OpenBSD and FreeBSD can share the driver without any significant
> differences.
> 
> However, the Bt848 include its own i2c bus, accessed through a port (a
> couple of the registers on the chip control all the access; addressing
> etc has to be addressed through this).  I'd like to export this as its
> own bus space, as it fit the bus space API perfectly.  There are a
> couple of 'sub-drivers' that will access this space - including the
> tuner drivers and the MSP drivers (for NICAM sound etc).
> 
> As far as I'm able to tell, this is not possible to do using the
> present bus spaces, as a driver cannot introduce a new tag and have
> callbacks for the bus_space_write_X functions etc.
> 
> Is there any idom for handling situations like this?

Uhm....

not really.

Of course, you could change all architectures bus_space_xxx() installation to
use a function pointer array, but this is not necessarily wise, as some 
architectures currently can get away with in-line macros for the bus_space
methods.

I'd propose to define an abstract "i2c" bus, which is provided by your bt
device port driver, or by something else, and provides two access function
pointers. The chip drivers would then attach to it.

I did something similar for Dallas Semiconductors chip bus:

sys/dev/ic/ds.h
sys/arch/amiga/dev/drbbc.c

[Here, actually drbbc.c contains the master device defining the ds bus 
as well as the slave device code attached to it, but in a perfect world,
this would be seperate.]

Regards,
	-is