In message <199806092037.NAA09969@lestat.nas.nasa.gov>  Jason Thorpe wrote:
> On Tue, 09 Jun 1998 21:32:44 +0200 
>  Stefan Grefen <grefen@hprc.tandem.com> wrote:
> 

>  > I can't find anything there that mandates that data-pointers have to be 
>  > aligned differently than in 'normal' code. 
>  > 
>  > I think the __BUS_SPACE_ADDRESS_SANITY checks for the data pointer should
>  > use ALIGNED_POINTER (but than the CPU will find those anyway :-)) ).
> 
> But the idea is that:
> 
> 	(1) i386 port (where the drivers are more heavily used) can find
> 	    the bugs for other platforms.

I aggree, but please with a additional switch. This is helpful for
driver development but not for daily use.

> 
> 	(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.

> 
>  > I would hate to have to copy the mbuf data on a slow i386SX running
>  > diskless, because some fast RISC ships can't do unaligned access :-)))
> 
>  > It is a driver for the CS8900 lan driver, I ported from the SHARK tree to
>  > i386. It's work in progress because it has to be tested again in the
>  > SHARK tree (I'm waiting for hardware). 
> 
> Aha... this driver was already fixed up for alignment checking!  Look
> at the arm32/isa/if_cs_isa.c:2999 (csCopyTxFrame).

I took the old 1.2 based stuff or so from the DEC site some time ago.
And this stuff is not in sup-tree so far.

> 
>  > PS.
>  > Code sniplet:
>  >                 if(!ALIGNED_POINTER(p,u_int16_t)) {
>  >                     /*
>  >                      * THIS IS UGLY
>  >                      */
>  >                      m0=m_pullup(m,len);
>  >                      continue;
>  >                 }
>  > 		...
>  > 		 bus_space_write_multi_2(sc->sc_iot,sc->sc_ioh,
>  > 		     PORT_RXTX_DATA,p,(len>>1) );
> 
> Hm... a different type of CS8900?  The code in the Shark tree uses
> write_region_2 to write the transmit buffer... :-)

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.

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. ---