Hey Sumit,
Op 06-08-12 08:41, Sumit Semwal schreef:
> Hi Maarten,
> On 27 July 2012 19:09, Maarten Lankhorst
> <maarten.lankho...@canonical.com> wrote:
>> A dma-fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering. The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
> Since Rob is the original author of this (and I the next?), may I
> request you to re-submit with his "From:" bit?
>
> Rob / Daniel: comments on this series will help me line it up in
> for-next, and maybe even for 3.7-rc.
>
It's a bit of a collaboration actually, I have done a few minor tweaks
on top of the version I sent out for RFC, making it v6. I will send it
somewhere this week, but I wanted to be sure that it worked with the
Xorg server first, instead of just my minor testsuit:
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
I have created a few minor testcases that seemed to have shown that the i915
parts
work. It also shows that a race-free remove wait early is hard, and should
preferably not be done unless a fatal hardware error occurred.
Tree is currently at:
http://cgit.freedesktop.org/~mlankhorst/linux/log/
And is based on drm-next + some fixes from nouveau. The reason why is that I
need some patches from drm-intel-next for flushing list removal.
It will likely also interact with the deferred fput if it's still in the -next
tree, however it should hopefully not be a problem, since the best thing about
it is that deferred fput will fix a few deadlocks. :)
I want to test it some more first to see that no deadlocks occur, but the
final version for the nouveau series will have to be rewritten, since the
maintainer dropped a massive 'rewrite everything' patch series. However,
when I finish testing later this week against real Xorg instead of my,
smaller testcases, I'll be more confident that nothing major will break
and that the base and intel parts are ready for -next.
Cheers,
~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
