Subject: Re: bus_space_read/write_multi_stream?
To: Chris G. Demetriou <email@example.com>
From: Allen Briggs <firstname.lastname@example.org>
Date: 07/31/2000 16:43:06
> However, if what you're accessing is logically a byte stream (e.g. a
> string, or an ethernet packet) where you need the byte ordering to
> remain constant, that doesn't work so well.
OK. I get it...
This is, in fact, what the smc91cxx driver should be using instead of
bus_space_read/write_multi_2() since its data register is a FIFO
mapped across 2 or 4 bytes (depending on the chip rev, we just use 2).
> When this problem was noticed, some of the BE systems folks (i forget
> who, now 8-), came up with the bus_space_*_stream_* methods.
> They're the right thing, and every port should implement them (at
> least as no-ops). And they should be documented.
I can handle the documentation and implementation on mac68k. Right now,
though, bus_space_read_stream only shows up in bus.h for
Since the bus_space_*_stream_ functions can be no-ops if the host cpu
and the bus are of the same endian, I guess most LE ports are fine (are
there any LE ports with non-LE busses?) and can just have a series of
#define bus_space_read_stream_1 bus_space_read_1
#define bus_space_read_stream_2 bus_space_read_2
#define bus_space_read_stream_4 bus_space_read_4
#define bus_space_read_stream_8 bus_space_read_8
#define bus_space_read_multi_stream_1 bus_space_read_multi_1
#define bus_space_read_region_stream_1 bus_space_read_region_1
#define bus_space_write_stream_1 bus_space_write_1
#define bus_space_write_multi_stream_1 bus_space_write_multi_1
#define bus_space_write_region_stream_1 bus_space_write_region_1
Is that right? If so, would it be OK for me to update the bus.h for
the ports that I know to be solely LE?
Also, I notice that, for the most part, there is no
bus_space_set_region_stream_N defined. Is that correct? I don't really
see much of a need for this, although it might make sense to have it for
completeness. I don't see a reason for _stream_ versions of copy_region
as they don't make sense.
Please help me get this right so I can get the documentation right... ;-)
Right now, there is some float between implementations (as one might
expect since the specification is "like it was done over in X").