Subject: Re: sparse vs. dense pci space
To: Chris G. Demetriou <>
From: Andrew Gallatin <>
List: port-alpha
Date: 12/15/1997 15:50:14
Chris G. Demetriou writes:
 > [ As always, not the opinions of Digital, not necessarily meant to
 >   indicate current or future behaviour of firmware or systems,
 >   etc... ]
 > > I eventually turned on extent debugging in
 > > arch/alpha/pci/cia_swiz_bus_mem.c From the output of the debugging
 > > printfs in pci_swiz_bus_mem_chipdep.c, it looks like I'm getting back
 > > a handle for a sparse address.  The problem is that I need a
 > > dense-space address.  I came up with a gross workaround to force
 > > bus_space_map to give me back the sort of address I can use.  Doing
 > > what I'm doing right now strikes me as wrong; can somebody offer a
 > > suggestion as to how I should approach this?  Since there isn't a way
 > > to specify dense/sparse, I think I must be doing something wrong.
 > By default, use of dense vs. sparse is determined based on whether the
 > region is cacheable/prefetchable.  You can probably hack around this,
 > but you shouldn't.  I'll let you hang yourself; here are the
 > instructions:  8-)

Thanks, I had a feeling you might be the one to answer this.  All I
needed was the same rope that DU provides me with. ;-) 
I'm off to see how well it fits 'round my neck.

 > I say non-portable because direct linear access may not be supported
 > at all, either for the hardware you're accessing or on the
 > architecture you're using.  I seem to recall that there are alphas
 > which do not _implement_ dense space, and that there are alphas which
 > do not implement "overlapping" dense and sparse space (i.e. something
 > can either be accessed via dense space, or accessed via sparse space,
 > picked by the firmware based on the 'prefetchable' bit).  (The PCI
 > mapping code uses that bit to determine whether or not to add the
 > 'cacheable' flag in, so if linear mapping were the right thing, you'd
 > already be getting it.)  Portable (between multiple architectures and

Well, assuming the manufacturer had set that bit.  The board (or at
least most of the software they provide) depends on linear access, I
went & looked at the econfig space for a myrinet board (0x804310E8) and
for the TGA (0x00041011, to see what it should look like).

	>>>e -l -n 4 econfig:C0000
	econfig:            C0000 804310E8 
	econfig:            C0004 04000046 
	econfig:            C0008 00000001 
	econfig:            C000C 0000FF00 
	econfig:            C0010 82000000 
	>>>e -l -n 4 econfig:B0000 
	econfig:            B0000 00041011 
	econfig:            B0004 02800087 
	econfig:            B0008 03800002 
	econfig:            B000C 0000FF00 
	econfig:            B0010 88000008 

So, in order to specify that the board needs linear access, you're
saying that 0xC0010 should be '0x88000008' like it is in the TGA,