From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Ben Widawsky <benjamin.widawsky@intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/bdw: MU_FLUSH_DW a qword instead of dword
Date: Wed, 5 Mar 2014 14:38:50 -0800 [thread overview]
Message-ID: <20140305223849.GA24362@bwidawsk.net> (raw)
In-Reply-To: <20140305223021.GA3559@nuc-i3427.alporthouse.com>
On Wed, Mar 05, 2014 at 10:30:21PM +0000, Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 11:05:15AM -0800, Ben Widawsky wrote:
> > On Wed, Mar 05, 2014 at 07:33:11PM +0100, Daniel Vetter wrote:
> > > On Wed, Mar 05, 2014 at 09:24:34AM +0000, Chris Wilson wrote:
> > > > On Tue, Mar 04, 2014 at 09:38:56AM -0800, Ben Widawsky wrote:
> > > > > The actual post sync op is "Write Immediate Data QWord." It is therefore
> > > > > arguable that we should have always done a qword write.
> > > >
> > > > Not really since the spec explicitly says that we can choose either a
> > > > dword or qword write. Note that qword writes also currently require a
> > > > 64 byte alignment.
> > >
> > > Yeah, that's also my reading of the spec - the lenght field selects
> > > whether the hw does a qword or dword write, and the qword needs to be
> > > specially aligned.
> > > -Daniel
> >
> > I think both of you only read this sentence, where I said it was
> > "arguable." The rest of the commit message was what actually mattered.
>
> I'm just arguing that the changelog is misleading. What we are doing is
> papering over an elephant, and more importantly I think it overlooked
> the extra restrictions imposed upon qwords (though it looks like we
> fortuituously are ok). The changelog also implies that all our other
> code is similarly flawed.
It wasn't completely fortuitous, I did check. I was lucky you think my
check was satisfactory though. I agree it makes future code somewhat
risky so maybe some improvement is needed to safeguard. I also have/had
a patch to lengthen MI_STORE_DATA_INDEX. The decoder however does not
complain about that one, and the windows team did neither. So I didn't
want to change it for the sake of change.
I think the reasons for FLUSH_DW are valid, but as it seems unrelated to
the actual root cause of the bug, I'll leave this one to the fates.
>
> The actual patch of splitting the code up into separate gen8 routines I
> thought was a nice improvement in readibility.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-03-05 22:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 17:38 [PATCH] drm/i915/bdw: MU_FLUSH_DW a qword instead of dword Ben Widawsky
2014-03-05 9:24 ` Chris Wilson
2014-03-05 18:33 ` Daniel Vetter
2014-03-05 19:05 ` Ben Widawsky
2014-03-05 22:30 ` Chris Wilson
2014-03-05 22:38 ` Ben Widawsky [this message]
2014-03-05 23:13 ` Damien Lespiau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140305223849.GA24362@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=benjamin.widawsky@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.