|| ||Zhenyu Wang <email@example.com>|
|| ||Dave Airlie <firstname.lastname@example.org>|
|| ||[RFC][PATCH 0/4] enabling graphics memory dma remapping|
|| ||Tue, 18 Dec 2007 13:08:09 +0800|
|| ||LKML <email@example.com>,
Keith Packard <firstname.lastname@example.org>,
Eric Anholt <email@example.com>,
"Gross, Mark" <firstname.lastname@example.org>|
Intel IOMMU (a.k.a VT-d) is under rapid deployment on desktop
and mobile platforms. As platform provides multiple dma remap
engines for devices like those lives on south bridge (net, sound,
etc.), and we also have one engine specific to graphics device.
If this engine is functioning, the access to graphics memory
routine is to first look up in GART table, which return virtual
dma address that will further be route to graphics DMAR engine,
which then looking up DMAR table to get real physical address.
Current intel iommu function in kernel is providing a graphics
workaround kernel config (CONFIG_DMAR_GFX_WA) to make a 1:1 mapping
initialization for graphics device, so what we fill in GART table
got from agpgart page alloc is identical to virtual dma address in
DMAR table. No change needs to be made for graphics driver.
Following patches try to add dma remapping function to agpgart
module, so we won't depend on intel iommu graphics workaround.
As DMAR is only available on x86_64 now, so these patches can only
work for x86_64 system.
Here're three patches below:
This exports current status of graphics dma remap engine, which
depends on current platform iommu support, kernel config or runtime
config. This info will be used in agp module for detect whether
we should do remapping or not.
This adds new hooks into agp bridge driver to do map/unmap when
bind/unbind memory into GART table. The aim is to provide generic
interfaces to let driver implement hardware specific operations.
This implements graphics dma remapping support in intel_agp module,
current only desktop chipset G33 series can use it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/