On Mon, 02 Feb 2004 12:25:33 +0530
"Anand Lalgondar" <solarflares@fastmail.fm> wrote:

> 1. Bus spaces are described by bus space tags, which can only be
> created by machine-dependent code. 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.
>    - 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.
Maybe, this depends on your hardware and the used bus bridges. (If there
is one.) E.g. on PowerPC the CPU itself has only memory space, no I/O
space like some Intel CPUs. A PCI bus has memory and I/O space. So on a
PPC machine with PCI bus you have no "native" CPU instructions to access
I/O space. The solution by the PCI host bridge is to map the PCI memory
and PCI I/O space to different ranges of CPU memory space. I.e. when the
CPU access phys. addr. 0x80000000 to 0xBFFFFFFF the PCI bridge
translates it to a PCI I/O transaction in the PCI address range
0x00000000 to 0x3FFFFFFF. When the CPU access phys. address 0xC0000000
to 0xFFFFFFFF the PCI bridge translates it to a PCI memory transaction
in the PCI address range 0x00000000 to 0x3FFFFFFF. Thus you have two bus
spaces / tags for PCI I/O and PCI memory.

> 2. Architectures may have several different tags which represent the
> same type of space, for instant because of multiple different host bus
> interface chipsets.
Maybe, this depends on your hardware and the used bus bridges. Maybe you
have two host bridges in different areas of your CPU memory address
space. When you access objects in the first bus you need to do endianes
conversion and you don't need this to do on the other bus bridge.

>    - Are these addresses pointing to physical addresses.=20
The kernel runs under control of the MMU, so the actual adresses depends
on how you choose to map the address range(s) of the bus bridge(s). At
least on PPC architectures it seems to be common to do a 1:1 physical to
virtual mapping.

> 4. Access to regions of bus space is facilitated by use of bus space
> handles, which are usually created by mapping a specific range of a
> bus space.
>    - bus_space_map function should be used to get the same - but I
>    could not find one in the MIPS specific directory.
See
__BS(map)(void *v, bus_addr_t addr, bus_size_t size, int flags,
    bus_space_handle_t *hp, int acct)
in the file you mention below.

> 5. Handles may also be created by allocating and mapping a range of
> bus space, the actual location of which is picked by the
> implementation within bounds specified by the caller of the allocation
> function.
>    - Is it like this -> some on-board peripherals/devices (ROM, SDRAM,
>    RTC, Ethernet Chip) have been allocated fixed physical address
>    range(Registers) by the board designer, so only option is to map
>    them and use the bus space functions to access the registers of the
>    on-board peripherals/devices?
Yes.=20

> 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.
Yes. It makes the actual device driver independent of the underlying bus
implementation.

>    - Now is this with respect to a device driver file or the
>    'sys/arch/mips/bus_space_alignstride_chipdep.c'
Device driver file. bus_space_alignstride_chipdep.c is the file that
implements bus_space.
--=20


tsch=FC=DF,
       Jochen

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