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>