Subject: Re: linear and non-cacheable mapping vs bwx
To: None <>
From: Chris G. Demetriou <>
List: port-alpha
Date: 09/01/1999 16:11:09
Matthias Drochner <> writes:
> I've got the impression that bwx provides a kind of
> non-cacheable "dense" space.
> So the check in
> arch/alpha/pci/pci_bwx_bus_mem_chipdep.c:CHIP_mem_map():
>         if (linear && !cacheable)
>                 return (EOPNOTSUPP);
> should go.
> Can one of the experts confirm this?

I don't necessarily think it should go.

Linear access should only be allowed if the region behaves like memory
from the kernel's point of view.

There are two ways this can be achieved: if the memory is cacheable,
or if you know that you're going to be accessing it in such a way that
memory and device access is going to be equivalent.

In other words, if you say:

	localvar = *(volatile uint8_t *)devmem

and devmem is prefetchable (what the code means by cacheable there,
for this example; on PCI alphas, unless i'm mistaken and/or forgetful,
no device memory will be cached, it's a matter of whether or not it
can be prefetched/write-combined, and maybe only prefetched), it
doesn't matter if that's done via an ldq{,_u} or ldl or an ldbu.

However, if devmem is not cacheable, then the difference between
ldl or ldq{,_u} and ldbu is going to be significant.  Unless you can
guarantee the latter type of access for the code above, linear mapping
shouldn't be allowed if the device memory isn't prefetchable.

In other words, getting right of the 'cacheable' check is probably

	* if you're compiling the kernel (and userland, if device
	  space mapping is ever exported from the kernel in some sane
	  manner) with BWX extensions, and

	* we're sure that enabling those those extensions will cause
	  the right kinds of accesses to be generated by the compiler.

Otherwise, it's not such a good idea.

Chris Demetriou - -
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.