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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
