From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Add OACONTROL to the command parser register whitelist. Date: Fri, 28 Mar 2014 07:36:25 +0000 Message-ID: <20140328073625.GA4530@nuc-i3427.alporthouse.com> References: <1395813123-2027-1-git-send-email-kenneth@whitecape.org> <20140326062123.GO26878@phenom.ffwll.local> <20140326160358.GA11367@bdvolkin-ubuntu-desktop> <20140326163820.GV26878@phenom.ffwll.local> <53331068.7090007@whitecape.org> <20140326182605.GA28133@bdvolkin-ubuntu-desktop> <20140327075721.GA26878@phenom.ffwll.local> <20140327155708.GA4690@bdvolkin-ubuntu-desktop> <20140327234221.GA21132@bdvolkin-ubuntu-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (mail.fireflyinternet.com [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id 982A56EBDD for ; Fri, 28 Mar 2014 00:36:30 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140327234221.GA21132@bdvolkin-ubuntu-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Volkin, Bradley D" Cc: Daniel Vetter , "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org On Thu, Mar 27, 2014 at 04:42:21PM -0700, Volkin, Bradley D wrote: > On Thu, Mar 27, 2014 at 01:16:26PM -0700, Daniel Vetter wrote: > > On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D > > wrote: > > > On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote: > > >> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's > > >> an issue with the test or the checker: > > >> > > >> https://bugs.freedesktop.org/show_bug.cgi?id=76670 > > > > > > For this one, the parser rejects an MI_STORE_REGISTER_MEM with the GGTT bit > > > set. We don't currently allow that, even from master. It sounds like there > > > might be released versions of the ddx that do this as well. If that's the > > > case, or if there are other situations where tests, etc rely on being able > > > to do whatever they want when setting the I915_DISPATCH_SECURE flag, then I > > > think we might as well stop parsing secure batches and let them go through > > > as before. > > > > Well for the testcase I think we can just add the missing flag. If > > Which flag are you referring to here? Or are you just generally trying to say > "modify the test to not break the rules"? > > > there's indeed shipping userspace out there which is getting these > > flags wrong then I think we need to silently upgrade them when copying > > the cmds over to the 2nd batch. But I guess until that need is really > > established we can hope we don't need this. > > Chris, can you clarify whether shipping ddx sets GGTT bits this way? There have been no point releases with SRM (as far as I can remember) as no bug reporter said that they made any difference to their hangs. -Chris -- Chris Wilson, Intel Open Source Technology Centre