Subject: Re: Fwd: Re: Queries about bus_space (MIPS: TX49)
To: Anand Lalgondar <solarflares@fastmail.fm>
From: Jochen Kunz <jkunz@unixag-kl.fh-kl.de>
List: tech-kern
Date: 02/03/2004 10:46:28
On Tue, 03 Feb 2004 11:15:07 +0530
"Anand Lalgondar" <solarflares@fastmail.fm> wrote:

> 1. To create a new tag (which is done in the machine dependent layer)
> an instant of bus_space_tag_t should be declared and to use the tag it
> should be initilaized by calling __BS(init) function call by declaring
> some macros and including 'bus_space_*_chipdep.c'.=20
Yes, somthing like this.=20

> But is it neccessary
> to create all the tags before autoconfiguration process?=20
What do you mean with "all the tags"? You have only one. (Or maybe two
for distinct I/O and memory spaces. But this depends on your hardware
and implementation.) All tags (bus space and bus dma) must be valid at
the start of autoconfig. The tags are passed along down the device tree
in the attach args. Device drivers copy them to there internal data
structures at attach time.

> 2. bus_space_map function call is used to create a new handle to
> access the requested bus range specified by address, size and flags.
Yes.

> 3. But, will the bus space framework display error when an out of
> range memory area is accessed. Well I think it is implementation
> dependent on a particular architecture.
This is implementation dependent.=20

> 4. What is the purpose of the void* cookie the first argument of the
> bus_space_tag_t. I found out that it holds the address of the
> structure(the second argument of __BS(init)) that contains the tag
> declaration.
You can pass an implementation dependent "cookie" along with the tag.
This "cookie" can contain some extra data to special case some things or
the like. Most likely you will not need it.

> > Note that this is only one possible implementation of bus space. ;-)
> Now what does this mean?
This means you can, but you don't have to use "bus_space_*_chipdep.c".
You can brew your own bus space beer as long as your implementation
conforms to bus_space(9). ;-)

> I have seen some drivers that have overriden the
> bus_space_read/write functionality by having there own functions.
Some drivers replace bus_space_read/write with own macros that are
shorter or some drivers are older then bus_space(9). They used some
read/write macros from the begining and later these macros where changed
to use bus_space_read/write.
--=20


tsch=FC=DF,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/