Re: [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active

From: Daniel Vetter <daniel@ffwll.ch>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Jani Nikula <jani.nikula@intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active
Date: Thu, 20 Mar 2014 10:45:31 +0100	[thread overview]
Message-ID: <CAKMK7uHdYmbjLRWYpvm_ROc7nYjp_HRfuRfyC_gBqGmg3jQSDQ@mail.gmail.com> (raw)
In-Reply-To: <1395301759.19007.66.camel@shinybook.infradead.org>

On Thu, Mar 20, 2014 at 8:49 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Thu, 2014-03-20 at 09:36 +0200, Jani Nikula wrote:
>>
>> Or an additional knob, in case it's really not working and people want
>> to get other things depending on prelim hw support done.
>
> Yeah. Perhaps the best answer is a 'disable_silicon_workarounds' option,
> to disable *all* workarounds for silicon bugs. Couple that with a printk
> telling the user that workarounds are disabled *and* VT-d is enabled.
>
> That's a nice simple thing for the chipset validation folks to be
> looking for. Unless they see that and have no issues with either
> framebuffer or X, the chipset hasn't been tested.
>
> That aside, I'm also unhappy with your patch on general principles. As a
> rule I'd like to see references to a *specific* published erratum, for
> anything we disable. Otherwise we're just admitting that life is too
> hard and we *never* bother to test our silicon before we ship it and we
> *expect* it to be broken.
>
> If we chase broken hardware to the point where errata are published, we
> should hopefully ensure that the problem feeds back to the validation
> folks who haven't done their job properly. Every time.
>
> (Pondered making this an internal email, but hey -- *you're* the one who
> said "our hardware is always broken and we don't even bother to track
> individual brokenness". I'm just translating it into English from what's
> in your patch :)

I'd agree that this would be nice, but my maintainer time is not
endless and when I have users screaming "regression" I do have to do
something. And yeah with the track record set of some of the earliest
vtd+gfx chips I'm fairly aggressive with just disabling features,
especially when the original bug report is against a recent platform
like ivb (so presumably issues on olders exist, too).

Now this very likely is some fumble in our code, after all the bios
managed to set things up. But until I have managers screaming at me
and throwing people ("resources") at the problem, my only concern is
keeping the regressions out the door without disabling other stuff my
managers actually do scream around about.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch