On Wed, Jul 10, 2013 at 5:18 PM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: >> So after a bit of irc chatting with Maarten this seems to be more >> involved. The above check is to cache the dma mapping, but the >> implementation is bogus in tons of ways: >> - If direction changes we don't bother with unmaping and freeing the >> mapping, but simply leak it. >> - This will break if the dma mapping needs explicit syncing since the >> helpers don't call sync_to_cpu/sync_to_device anywhere. > > Right, and I believe I signed up for that. Well, the breakage runs deeper since atm ttm doesn't have any concept of syncing from/to the device dma. Neither has i915. So this little issue here is just the tip of the iceberg ... >> So I think I'll decline to poke around more in this hornet nest and >> leave it at the locking removal. > > .. and I get the hornet nest :-). Is there a IRC log of what you guys talked > about so I don't omit certain pieces of code. The above is pretty much the summary, actually more lines than what we've discussed on irc ;-) It's on #dri-devel though: http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2013-07-10 -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
