> I have some queries regarding 'bus_space' functions, [...]

Well, I'm no bus-space guru, but I do have the time, and I think I know
a little about the bus-space paradigm.  I'm sure someone will slap me
down if I start spouting nonsense.

> 1. Bus spaces are described by bus space tags, which can only be
> created by machine-dependent code.

Right.

> A given machine may have several different types of bus space (e.g.
> memory space and I/O space), and thus may provide multiple different
> bus space tags.

Right.

>    - Now as per my knowledge there is nothing like I/O space in TX49
>    architecutre (is it correct), so the only bus space tags that can
>    be created would be of type memory bus space.

Perhaps at the moment (I don't know).  What you need to do may be to
create a new bus space for your port.  It may be instructive to examine
the i386 implementation, since that does have to deal with an I/O space
that is not accessed like memory.

I once did this.  I had to deal with hardware that had a serial chip of
a type supported by a MI driver, but connected oddly - the CPU-visible
effect was that all addresses relative to the base of the chip were
multiplied by some small constant, 16 I think, by wiring "unusual"
address lines to the relevant chip inputs.  The MI driver, though,
expected to access the registers at small fixed offsets from the
bus-space values passed to it by its attachment.

So I took the bus-space implementation of the port I was working on and
added a new bus space, one whose methods multiplied the offset by the
appropriate constant...it was a kludge, but it worked.

> 6. The goal of the bus_space functions is to allow a single driver
> source file to manipulate a set of devices on different system
> architectures, and to allow a single driver object file to manipulate
> a set of devices on multiple a set of devices on multiple bus types
> on a single architecture.

Right.  For example, with the above hack, I could use the MI driver for
that chip unchanged - indeed, I think I used the same MI driver to
drive both the oddly-connected chip and other instances of the same
chip (attached more conventionally) on the very same machine, exactly
the sort of abstraction bus-space is designed to support.

If I had a _really_ funky attachment for that chip - say, one where
everything went through two memory-mapped locations, and accessing a
chip register means writing its offset to location A and then accessing
location B - I could have supported it with a bus-space tag type with
correspondingly funky implementation code backing it.  (Some chips
already use such a scheme; drivers for them are prepared to deal with
it.  But for chips that aren't normally done that way, the drivers
aren't normally done that way either.)

> Well I have some more queries w.r.t bus space of MIPS architecture,

Well, it does occur to me that some of your questions cannot really be
answered, because they depend not on the MIPS architecture per se but
rather on how the machine outside the CPU is put together.  Compare the
bus-space implementations for the various MIPS-based ports....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B