From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 23:30:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C0DF16A4DE; Wed, 5 Jul 2006 23:30:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B722143D49; Wed, 5 Jul 2006 23:30:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k65NUqFm057530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 16:30:53 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44AC4BAC.4040105@errno.com> Date: Wed, 05 Jul 2006 16:30:52 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: John Baldwin References: <20060629111231.GA692@wolf.nvidia.com> <20060702.220217.2073896080.imp@bsdimp.com> <200607051211.58386.jhb@freebsd.org> In-Reply-To: <200607051211.58386.jhb@freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 23:30:56 -0000 John Baldwin wrote: > On Monday 03 July 2006 00:02, M. Warner Losh wrote: >> In message: <20060629111231.GA692@wolf.nvidia.com> >> Christian Zander 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