Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard <keithp(a)keithp.com>
Cc: Ben Widawsky <ben(a)bwidawsk.net>
---
Here's a shorter patch which just elides the body of the needs_idle_maps functions
drivers/char/agp/intel-gtt.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/…
[View More]char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 3a8d448..c92424c 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1186,10 +1186,11 @@ static void gen6_cleanup(void)
/* Certain Gen5 chipsets require require idling the GPU before
* unmapping anything from the GTT when VT-d is enabled.
*/
-extern int intel_iommu_gfx_mapped;
static inline int needs_idle_maps(void)
{
+#ifdef CONFIG_INTEL_IOMMU
const unsigned short gpu_devid = intel_private.pcidev->device;
+ extern int intel_iommu_gfx_mapped;
/* Query intel_iommu to see if we need the workaround. Presumably that
* was loaded first.
@@ -1198,7 +1199,7 @@ static inline int needs_idle_maps(void)
gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
intel_iommu_gfx_mapped)
return 1;
-
+#endif
return 0;
}
--
1.7.7
[View Less]
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a bit of discussion on the mailing list
http://marc.info/?i=4D769726.2030307@shipmail.org I started working on it, but
got waylaid by other things .. and finally I am able to post the RFC patches.
There …
[View More]was a lot of discussion about it and I am not sure if I captured
everybody's thoughts - if I did not - that is _not_ intentional - it has just
been quite some time..
Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a
DMA pool that the device has associated with. I kind of married that code
along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code.
The end result is DMA pool with extra features: can do write-combine, uncached,
writeback (and tracks them and sets back to WB when freed); tracks "cached"
pages that don't really need to be returned to a pool; and hooks up to
the shrinker code so that the pools can be shrunk.
If you guys think this set of patches make sense - my future plans were
1) Get this in large crowd of testing .. and if it works for a kernel release
2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox
about it and he is OK as long as I don't introduce performance regressions).
But before I do any of that a second set of eyes taking a look at these
patches would be most welcome.
In regards to testing, I've been running them non-stop for the last month.
(and found some issues which I've fixed up) - and been quite happy with how
they work.
Michel (thanks!) took a spin of the patches on his PowerPC and they did not
cause any regressions (wheew).
The patches are also located in a git tree:
git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v2.1
Konrad Rzeszutek Wilk (11):
swiotlb: Expose swiotlb_nr_tlb function to modules
nouveau/radeon: Set coherent DMA mask
ttm/radeon/nouveau: Check the DMA address from TTM against known value.
ttm: Wrap ttm_[put|get]_pages and extract GFP_* and caching states from 'struct ttm_tt'
ttm: Get rid of temporary scaffolding
ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
ttm: Do not set the ttm->be to NULL before calling the TTM page pool to free pages.
ttm: Provide DMA aware TTM page pool code.
ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime.
nouveau/ttm/dma: Enable the TTM DMA pool if device can only do 32-bit DMA.
radeon/ttm/dma: Enable the TTM DMA pool if the device can only do 32-bit.
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 1 +
drivers/gpu/drm/nouveau/nouveau_mem.c | 5 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 8 +-
drivers/gpu/drm/radeon/radeon_device.c | 6 +
drivers/gpu/drm/radeon/radeon_gart.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 19 +-
drivers/gpu/drm/ttm/Makefile | 3 +
drivers/gpu/drm/ttm/ttm_memory.c | 5 +
drivers/gpu/drm/ttm/ttm_page_alloc.c | 108 ++-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1446 +++++++++++++++++++++++++++++
drivers/gpu/drm/ttm/ttm_tt.c | 21 +-
drivers/xen/swiotlb-xen.c | 2 +-
include/drm/ttm/ttm_bo_driver.h | 31 +
include/drm/ttm/ttm_page_alloc.h | 53 +-
include/linux/swiotlb.h | 2 +-
lib/swiotlb.c | 5 +-
16 files changed, 1637 insertions(+), 82 deletions(-)
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #56 from Travis Glenn Hansen <travisghansen(a)yahoo.com> 2011-10-31 19:59:41 PDT ---
Alex
Thanks for continuing to look at this :) I have converted my amd machine to a
server so I'm not using it (or rebooting it for that matter) with an external
monitor. However I ran through some updates today and decided to hook it up to
provide feedback. I updated to 3.1.0 (gentoo variant) and it continues to fail
for me :( After …
[View More]looking at the patch it appears to either be in vanilla 3.1.0
or already included in the gentoo patchset. To summarize, I've tried 3.1.0
with the patch from the link and it doesn't work with my setup.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)
The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by detecting them faster.
The second fix replicates the first one within the i915 driver. It does the
same thing, but without touching core DRM files.
Those are some of the testing results from our QA …
[View More]team:
Regressions and functional testing:
Machine+ports result
Ironlake(mobile) eDP/VGA pass
Ironlake(desktop) DP/VGA pass
Ironlake(mobile) LVDS/VGA/DP pass
G45(desktop) VGA/HDMI pass
Pineview(mobile) LVDS/VGA pass
xrandr performance:
Without patch with patch
E6510(Ironlake mobile) 0.119 0.111
PK1(Ironlake desktop) 0.101 0.080
T410b(Ironlake mobile) 0.406 0.114
G45b( G45 desktop) 0.121 0.091
Pnv1(Pineview mobile) 0.043 0.040
Those are the results for machines affected by phantom outputs issue, based on
fd.o #41059 feedback:
xrandr performance:
Without patch with patch
System 1 0.840 0.290
System 2 0.690 0.140
System 3 0.315 0.280
System 4 0.175 0.140
System 6 (original issue) 4s 0.184
We have observed no regressions in any cases, and performance improvements
of 20-30% for edid detection timing. Combining it with the results obtained
at https://bugs.freedesktop.org/show_bug.cgi?id=41059, besides those
improvements it also improves xrandr timing by up to 20x in the worst case
of phantom outputs.
I believe that the better way to fix this is via the drm_get_edid() fix, as
it is a one-line fix and could benefit all other chipsets. And we won't have
to reinvent the wheel with intel_drm_get_edid, which only duplicates the
existent functionality with no additional benefits.
Could we have any feedback or reviewed-by or from non-intel drm maintainers?
Thanks!
Eugeni Dodonov (2):
Give up on edid retries when i2c tells us that bus is not there
Check if the bus is valid prior to discovering edid.
drivers/gpu/drm/drm_edid.c | 5 ++++
drivers/gpu/drm/i915/intel_crt.c | 46 ++++++++++++++++++------------------
drivers/gpu/drm/i915/intel_dp.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_hdmi.c | 4 +-
drivers/gpu/drm/i915/intel_i2c.c | 42 ++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
drivers/gpu/drm/i915/intel_modes.c | 29 +----------------------
drivers/gpu/drm/i915/intel_sdvo.c | 4 +-
9 files changed, 80 insertions(+), 59 deletions(-)
--
1.7.7
[View Less]