On Mon, Sep 28, 1998 at 12:59:25PM +0200, Ignatios Souvatzis wrote:
> On Sun, Sep 27, 1998 at 09:13:54PM +0200, Eivind Eklund wrote:
> > 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 am thinking of introducing an 'ebus_space' (as in extended
bus_space) that implements the abstraction I want (ability define my
own bus spaces).  This would be the same API as the normal bus_space
API, but with a couple of additions, and slightly slower.  It would be
built on top of the normal bus_spaces, but with tags that also had a
set of callbacks, to be used if the tag itself is not directly
recognized and the operations done inline.

This will make the sub-drivers be almost exactly like the normal
bus-spaced drivers, and will make it easy to convert them if bus_space
is later extended to handle this sort of buses.

I'll see if I can implement this in terms of the relevant i2c
interfaces in NetBSD and FreeBSD (different abstractions :-(, but I'm
not quite certain this is practical - it result in an extreme amount
of layering, at least (but the i2c bus is slow, so it may not matter
much).

Neither of the i2c abstractions seems to have many devices implemented
for them (1 in FreeBSD, 1 in NetBSD, if I understand correctly - the
FreeBSD ThunderLan driver doesn't use the FreeBSD i2c abstraction, and
is totally independent of the NetBSD ThunderLan driver :-(.

> 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.]

This is almost the way the bt848 driver already does it.  However, I
dislike this on the basis that it create a totally different interface
for what is basically (at least for i2c the way the bt848 support
chips use it) covered by the same abstraction as normal bus_spaces.

Of course, we may gamble that nobody will implement anything that have
the same interface over i2c and other buses; however, this seems a
little dumb to me.

Eivind.