In message <199806092202.PAA10864@lestat.nas.nasa.gov>  Jason Thorpe wrote:
> On Tue, 09 Jun 1998 23:25:15 +0200 
>  Stefan Grefen <grefen@hprc.tandem.com> wrote:
> 
>  > I aggree, but please with a additional switch. This is helpful for
>  > driver development but not for daily use.
> 
> The DEBUG option isn't really "for daily use", either...  I guess you
> and I disagree on the semantics of the DEBUG option.

The problem is the message goes away without DEBUG, but a 'fixed'
driver stays. I can add a ifdef DEBUG in the driver around the 
alignment to force it to align if DEBUG is defined, but this practice
defeats the purpose.
The problem in this case is that the message really hurts so bad
that you won't run a system with DEBUG compiled in.
I still don't see why the alignment of the data pointer (not the
busspace address) needs to be stricter aligned than mandatory for the
CPU (unless you check for another architecture, which I think isn't covered
by DEBUG).

> 
>  > > 	(2) there may be a performance gain for doing aligned access on
>  > > 	    _any_ port, even when it is not strictly necessary.
>  > 
>  > Not if this is the transfer to the device. It would just introduce a
>  > copy of the data for no reason.
> 
> That's only because your m_pullup() does a copy; there are other ways of
> dealing with the problem.  See the CS8900 that _IS_ in the SUP tree at
> src/sys/arch/arm32/isa/if_cs_isa().  Look at csCopyTxFrame(), the last
> function in the file.  I agree that my example in the NE2000 driver is
> a bad one, and I'm planning on fixing it RSN.  (Needed to dig out an
> NE2000 to test with :-)

I'm supping current/allsrc every 8 hours (to cover for failures) and 
arch/arm32/isa is empty (just .keep_me).

I'm using ports, so it has to be 2 byte access and I think insw beats 
any other solution. Doing a dance through a tmp variable may be faster than 
a pullup, but still a lot slower than insw.
Since I'm using this 386 I'm looking at CPU-cycles again :-)) 
You stop doing that if you play with bigger machines in your day-time job.

> 
>  > No but I can't use the memory mapped or DMA mode. The chip is soldered on 
>  > a PC104 board and the EEPROM tells me that no Memory window or DMA is
>  > available.
> 
> Hm... for a generic CS8900 driver, sounds like we really want callbacks
> to the front-end to do the tx/rx buffer handling, then.

I've tried that, so I creates ic/cs8900 & friends, I'll merge my version 
with the current arm32 version as soon as I get a SHARK. 

Stefan

> 
> Jason R. Thorpe                                       thorpej@nas.nasa.gov
> NASA Ames Research Center                            Home: +1 408 866 1912
> NAS: M/S 258-5                                       Work: +1 650 604 0935
> Moffett Field, CA 94035                             Pager: +1 650 428 6939

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---