On 07/07/2013 19:17, David Herrmann wrote: > Hi > > This is v2 of the unified VMA offset manager series. The first draft is > available at LWN [1]. This series replaces the VMA offset managers in GEM and > TTM with a unified implementation. > > The first 4 patches contain the new VMA offset manager and are the only > patches > that I propose for mainline inclusion. > Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar > patches in i915-next and I will rebase them once it is merged. Ignore > them if you're not interested. > Patches 9-19 implement mmap access control. Comments are welcome! They are > intended for mainline inclusion, too, but probably require some more review > rounds. I'd really appreciate if driver authors could comment on the > implementation. > Patch 20 shows the main motivation behind this whole series: render nodes. It > is > marked RFC and I will resend once the VMA manager is merged upstream. Feel > free > to test it. > > One more note regarding DRM-Master: Render-clients are independent of > DRM-Master > (see the DocBook documentation). It really doesn't make sense to create/bind a > DRM-Master object to render-clients. However, a lot of core DRM code depends > on > ->master != NULL. Drivers need to take care not to call into those core > modules > if they implement DRIVER_RENDER. > I plan on removing multiple-master-support in the next series. So there will > be > only one global master and each open-file is bound to it. This will make it > very > easy to phase out "drm_master". The planned "modeset" nodes provide a nice > replacement. If anyone knows a **currently used** use-case for > multiple-masters, > please tell me. I couldn't find one that _actually works_. > (SetMaster+DropMaster > will obviously stay functional even with drm_master removed). > > > (series available at: https://github.com/dvdhrm/linux/tree/rnodes) > > Comments welcome! > Cheers > David Hi David,
Thanks for this patchset. I am away from my computers for testing but I was wondering if you based your vma rework on Dave's implementation. If so, you may have the same bug that I had with it. I cannot remember the details of the bug, but I could trigger it by rebooting kde around 13 times on radeon. I didn't have this problem with Nouveau. I am not competent to judge this work but I will try to test it and check with my security tests that I wrote that the problem is indeed solved on nouveau and radeon. Looking forward to seeing your proposition for the userspace :) Cheers, Martin
