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 <email@example.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. :)