Subject: Re: Adding bus_space_{peek,poke}_N() to bus_space(9)
To: Steve Woodford <scw@netbsd.org>
From: Jason R Thorpe <thorpej@zembu.com>
List: tech-kern
Date: 11/22/2000 11:20:23
On Wed, Nov 22, 2000 at 05:11:40PM +0000, Steve Woodford wrote:

 > I propose the following new functions, where `N' is 1, 2, 4 and 8:
 > 
 > 	int bus_space_peek_N(bus_space_tag_t tag,
 > 		bus_space_handle_t handle,
 > 		bus_size_t offset,
 > 		u_intN_t *valuep);
 > 
 > 	int bus_space_poke_N(bus_space_tag_t tag,
 > 		bus_space_handle_t handle,
 > 		bus_size_t offset,
 > 		u_intN_t value);
 > 
 > These will return zero if the read/write succeeded, otherwise non-zero if
 > the hardware terminated the cycle with an error (eg. a bus error). In the
 > case of `read', the location pointed to by `valuep' will contain the data
 > read. In the case of `write', the data written is `value'.
 > 
 > Right now, I'm not sure whether a `handle' is really necessary here since
 > the functions will mostly be used in a driver's XX_match() routine before
 > bus_space_map(9) is called. c.f. vme_probe() in the MI VMEbus space code.

Yes, the match routine must bus_space_map() the space first (ISA drivers
already do this) to ensure that it's mappable, and then probe the space
using peek/poke.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>