Date: Wed, 5 Jul 2006 23:42:28 -0400 From: John Baldwin <jhb@freebsd.org> To: Sam Leffler <sam@errno.com> Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests Message-ID: <200607052342.29273.jhb@freebsd.org> In-Reply-To: <44AC4BAC.4040105@errno.com> References: <20060629111231.GA692@wolf.nvidia.com> <200607051211.58386.jhb@freebsd.org> <44AC4BAC.4040105@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 05 July 2006 19:30, Sam Leffler wrote: > 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. I don't disagree, but my point is that the APIs do need extending. Look at it this way. The current changes are to provide a way so nvidia can call pmap_foo() functions rather than modifying PTE's and the PAT MSR's directly. This is progress. :) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607052342.29273.jhb>