Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 Jul 2006 16:30:52 -0700
From:      Sam Leffler <sam@errno.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, czander@nvidia.com
Subject:   Re: NVIDIA FreeBSD kernel feature requests
Message-ID:  <44AC4BAC.4040105@errno.com>
In-Reply-To: <200607051211.58386.jhb@freebsd.org>
References:  <20060629111231.GA692@wolf.nvidia.com>	<20060702.220217.2073896080.imp@bsdimp.com> <200607051211.58386.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Monday 03 July 2006 00:02, M. Warner Losh wrote:
>> In message: <20060629111231.GA692@wolf.nvidia.com>
>>             Christian Zander <czander@nvidia.com> writes:
>> : This summary makes an attempt to describe the kernel interfaces needed by
>> : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with
>> : the Linux/Solaris graphics drivers, and/or required to make support for
>> : the FreeBSD amd64 platform feasible. It also describes some of the
>> : technical difficulties encountered by NVIDIA during the FreeBSD i386
>> : graphics driver's development, how these problems have been worked around
>> : and what could be done to solve them better.
>>
>> Thank you for taking the time to let us know how we might make the
>> system better.
>>
>> :    The NVIDIA graphics driver needs to be able to create uncached kernel
>> :    and user mappings of I/O memory, such as NVIDIA GPU registers. The
>> :    FreeBSD kernel does not currently provide the interfaces necessary to
>> :    specify the memory type when creating such mappings, which makes it
>> :    difficult for the NVIDIA graphics driver to guarantee that the correct
>> :    memory type is selected.
>>
>> Is this via the bus_alloc_resource interface?  Is uncached kernel
>> memory different than non-prefetchable memory?  If so, please specify
>> how it is different.  If not, then we have an interface that will do
>> what you want, except it is only implemented for cardbus and would
>> need to be implemented for pci pci and pci host bridges.  Would having
>> better functionality here help?  I noticed it wasn't on the task list...
> 
> This isn't an issue of how the memory is mapped in the PCI-PCI bridge where 
> non-prefetchable is used to keep the bridge from prefetching things, but as 
> to how the memory is mapped in the CPU itself.  Also, I've seen mention of 
> using bus_dma, etc.  One of the problems is our current bus APIs have a very 
> limited view of caching "modes".  E.g. here you mention overloading 
> non-prefetchable to get a UC mapping.  In bus_dma(9) we have the COHERENT 
> flag to UC rather than a WB mapping.  Neither of these API's allow for, say, 
> WC (Write-Combining) mappings. :)  Other OS's such as Windows and OS X allow 
> you to explicitly specify what type of cache "mode" you want for a mapping.
> 

As we've discussed privately, bus_dma is the right api for drivers to
use.  If it doesn't do what he needs then we need to extend it.  Drivers
should not be groveling around inside the vm system.

	Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AC4BAC.4040105>