Re: Problems with mach64 on NetBSD/sparc64

Marc Aurele La France <[email protected]>
Newsgroups gmane.comp.xfree86.devel
Message-ID <[email protected]>
On Thu, 6 Oct 2005, Martin Husemann wrote:

> On Thu, Oct 06, 2005 at 01:39:10PM -0600, Marc Aurele La France wrote:
>> No.  My preference is definitely to keep the OS out of the way, as much as
>> possible

> Ok, but in this case that is not realy possible. You need a OS driver
> that understands your mmap() call anyway to get the IOMMU mappings
> correct & consistent.

> We do not allow generic mmap'ing of PCI memory ranges, because that would
> mean we had to try very hard to keep all OS drivers out of the way or
> somehow synchronize the userland mapping with them.

> On i386 with plain pass-through PCI access thinks are certainly different.

You're assuming the X server would indiscriminately trample all over such 
mappings.  That's not the case on SPARC any more than it is on x86.

I also don't see why this "is not really possible" with NetBSD, when it works 
very well through Linux and SunOS (... and I _do_ mean "through").

The idea here is to support PCI, not PCI/x86, PCI/SPARC, ad nauseam.  This 
means creating a generic model of PCI and filtering out host differences 
before presenting that model to our video drivers.  The less lobotomies of 
PCI the underlying OS implements, the better.  The only restriction on PCI 
this architecture actually implements is its default handling of master 
aborts.  And even that assertion is debatable.  _All_ other restrictions are 
necessarily OS inventions.

No matter how you look at it, some NetBSD kernel work will be required for 
multihead to work on both uni-domain (Sabre & Hummingbird) and multi-domain 
(Psycho, Schizo & Tomatillo) systems.

The first thing to look at is PCI I/O.  I see from the logs posted on this 
thread that the kernel clobbers OBP's assignment of PCI I/O BARs.  This 
clobbering needs to be removed.  There also needs to be an ability to map in 
one chunk the entirety of a host bridge's PCI I/O range.  Doing this mapping 
per device isn't practical because PCI limits assignments to 256 bytes (which 
is less than the host page size) and per-device mappings don't allow for 
unregistered assignments such as those for VGA, 8514/A, etc.

It doesn't really matter whether PCI memory mappings are done per-device, 
per-domain, or through some more liberal /dev/mem clone.  The caveat here is 
that should you require that such mappings be done per-device, you had 
better ensure even PCI ROM pointers are assigned, valid and mappable.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Academic Information and        |  fax:    1-780-492-1729           |
|    Communications Technologies   |  email:  [email protected]          |
|  352 General Services Building   +-----------------------------------+
|  University of Alberta           |                                   |
|  Edmonton, Alberta               |     Standard disclaimers apply    |
|  T6G 2H1                         |                                   |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 developer and VP.  ATI driver and X server internals.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.