Re: mpii_start() vs. mfii_start(): bus_space_write_raw_8(), bus_space_barrier()

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Tue, 11 Oct 2022 16:50:17 +0200
> From: Edgar Fuß <ef%math.uni-bonn.de@localhost>
> 
> void
> mpii_start(struct mpii_softc *sc, struct mpii_ccb *ccb)
> {
> 	struct mpii_request_header	*rhp;
> 	struct mpii_request_descr	descr;
> #if defined(__LP64__) && 0
> 	u_long				 *rdp = (u_long *)&descr;
> #else

Note the `&& 0' here -- this is dead code!  Only the else branch is
taken.

> #if defined(__LP64__) && 0
> 	bus_space_write_raw_8(sc->sc_iot, sc->sc_ioh,
> 	    MPII_REQ_DESCR_POST_LOW, *rdp);
> #else

Same here.

> 1. __LP64__ handling: Is the LP64 case simply an optimization or is it 
>    safer on the relevant platforms?

Depends on the hardware: some hardware supports 64-bit read/write
transactions on registers; some hardware does not, and `64-bit'
registers must be read/written in 32-bit halves.  It may be an
optimization on LP64 platforms, or it may be necessary for the
transaction to be atomic.

> 2. bus_space_write_raw_8(): I can't find any description or references for 
>    that function. Should that be bus_space_write_8()?

It appears to have been copied from OpenBSD, whose
bus_space_read/write_raw_* functions appear to correspond to NetBSD's
bus_space_read/write_stream_* functions -- they don't do any byte
order conversion, so the I/O device has to have the same byte order as
the CPU, which is unusual but happens sometimes.

Whether to use the stream or non-stream version depends on how the
device works, for which you'll have to consult the manual and/or do
science on it.  LP64 shouldn't make a differnce here -- the LP64 and
non-LP64 cases should agree on whether to use raw/stream or not, and
they do appear to agree in OpenBSD.

> 3. Single vs. double bus_space_barrier(): It strikes me as odd that 
>    mpii_start() has a call between the two bus_space_write_4() calls while 
>    mfii_start() hasn't. It also look suspicious to me that both calls use 
>    MPII_REQ_DESCR_POST_LOW.

Unless the bus space is mapped with BUS_SPACE_MAP_PREFETCHABLE, the
barrier calls are no-ops and can be flushed.  It is probably a
harmless mistake that both barriers use MPII_REQ_DESCR_POST_LOW -- the
second one was probably meant to use MPII_REQ_DESCR_POST_HIGH.