Subject: Re: Busspace sanity ...
To: None <grefen@hprc.tandem.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: port-i386
Date: 06/09/1998 13:37:21
On Tue, 09 Jun 1998 21:32:44 +0200 
 Stefan Grefen <grefen@hprc.tandem.com> wrote:

 > My point is that even if ALIGNED_POINTER() is true (always on a i386),
 > __BUS_SPACE_ALIGNED_ADDRESS() maybe false. 
 > The code in question does a ALIGNED_POINTER() and a pullup if that fails.
 > I consider that not broken.

Oh, I see... ack... Yes, we need to have a more strict version of alignment
checking... perhaps export a BUS_SPACE_ALIGNED_ADDRESS() macro to use
in place of ALIGNED_POINTER().

(Sorry, I'm too used to working w/ Alphas :-)

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

	(2) there may be a performance gain for doing aligned access on
	    _any_ port, even when it is not strictly necessary.

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

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

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