> > Thats true and I compeletely agree. But, when you want to write a driver
> > to an on-chip or on-board pheripheral device the first thing would be to
> > test the basic functionality of the device without bothering about the
> > bus_space tag/handle. Finally when the basic flow is ready then you have
> 
> I disagree.  Given a bus_space implementation for the port in question,
> using bus_space can make driver writing _faster_, because it makes the
> logic of things like updating device registers _clearer_, and thus
> much less error prone.
> 
In most of the evaluation boards the on-chip and on-board peripheral
devices would be mapped (registers of the peripherals), to some fixed
location that can be found out by referring the processor/chip and
eval-board manuals. The on-chip pheripheral registers can be mapped to a
configurable address if supported by the respective architecture. The
board designers considering all the cases of the architecture would map
the on-board peripherals to some fixed location. When this information is
available you don't have to spend time in understanding how to use bus
space to access the registers. The registers can be access with pointer
dereferrencing, where the pointer is actually pointing to the base
address of the registers. This will be helpful to understand the basic
initialization and flow of the device.

Next,
some peripheral device will support memory windows (that will be used by
the child devices or by itself). Generally each window is represented by
the peripehral by two specifying two options - 
1. physical base address
2. size
Now any physical address generated between the physical base address and
the size window would resolve down to the peripheral. And also the base
address registers can hold any physical address. It's up to the
programmer to decide what should be mentioned (the memory window should
not overlap). As the kernel operates only with virtual memory, the memory
window should be mapped to some virtual address. For this to be done, if
the programmer has the following list of information, that would help a
lot:
1. List of physical address and virtual address range already in use.
2. How to map a physical address to a particular virtual address.
3. Or does the architecture has a fixed virtual address mapping depending
on the architecture.

So, after the initial device testing, you require the bus space knowledge
and also know the memory ranges (physical/virtual address range) that are
used and free to avoid conflicts and make the driver as machine
independent.

> Certainly it is hard to concieve of using bus_space making a driver
> development process much longer, unless you're porting an entire
> driver from an operating system which doesn't have bus_space (and
> even then, converting to bus_space is the right way to make _sure_
> you didn't miss any endianness assumptions, etc.)
> 
Every on-chip peripheral device would be new since it depends on the
architecture, not with resepect to the operation of the device but with
respect to the interface between the peripheral and the processor(it is
completely dependent and this information can be grabbed from the manual
for initial testing).

Driver development can be done in two phases:
1. The actual testing of the peripheral, the response, interrupts,
timing, etc.
2. To interface it to the kernel as a device driver (CFATTACH) and
provide bus space to provide portability.

 - Anand

-- 
http://www.fastmail.fm - Sent 0.000002 seconds ago