Bug#697029: Which Ironlake chips need IOTLB sync
On Sun, Feb 24, 2013 at 07:24:33PM +0000, Ben Hutchings wrote:
> We had a report of slow graphics performance in Linux 3.2 and 3.7,
> apparently related to carrying out frequent IOTLB syncs.
>
> If I understand correctly, IOTLB and GTT changes must be serialised on
> Ironlake chips to avoid hangs (or access to the wrong memory address?).
> These commits seem to implement the workaround:
>
> commit 6fbcfb3e467adb414e235eeefaeaf51ad12f2461
> Author: David Woodhouse <dwmw2@infradead.org>
> Date: Sun Sep 25 19:11:14 2011 -0700
>
> intel-iommu: Workaround IOTLB hang on Ironlake GPU
>
> commit 5c0422878fcdc279ae9a8e8b66972a15b5efb67f
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date: Mon Oct 17 15:51:55 2011 -0700
>
> drm/i915: ILK + VT-d workaround
>
> The intel-iommu quirk is applied if any of these device IDs are found:
>
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_D_HB 0x0040
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB 0x0044
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_MA_HB 0x0062
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_MC2_HB 0x006a
>
> though not:
>
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_D2_HB 0x0069
>
> The intel-gtt quirk is applied if either of these are found as the IGP:
>
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB 0x0044
> #define PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG 0x0046
>
> but of course the first will never match.
>
> Does the bug affect Ironlake D or not?
>
First of all, this has changed a little bit for 3.8 (or is it 3.9?). The
logic should be a bit better. The latest check is moved to the i915 drm
driver, and is:
if (IS_GEN5(dev) && IS_MOBILE(dev) && intel_iommu_gfx_mapped)
return true;
Yes, the PCI id matching is weird. It was taken verbatim from the errata
doc, which I never had a link to, and never bothered to search for. It
made it sound like there was a PCI id rsvd for 0x44, which just never
made it to the wild. In any case, it made internal people happy, so I
just went with it. It seems bogus to me as well...
To the best of my knowledge, this only effected mobile chipsets, and the
proper check would have actually been to just check the PCI id of the
host bridge. The 3.8 check is much more appropriate IMO.
--
Ben Widawsky, Intel Open Source Technology Center
Reply to: