On Sun, Feb 21, 2010 at 10:44:31AM +0100, Thomas Hellstrom wrote: > Jerome, > > I think this could and should be accomplished in the following way (like > the old ttm did). > > 1: For kernel maps: > a) reserve the bo. > b) validate the bo into a mappable segment of vram, perhaps using range > validation. > c) idle any accelerated move. > d) call ttm_bo_kmap. > > 2: For fault: > a) in bo_driver::fault_reserve_notify, validate the bo into a mappable > segment of vram, perhaps using range validation. > b) The fault method will automatically idle any accelerated move. > > Is there something that could not be accomplished with this approach?
This approach doesn't allow to take advantage of 2 separate apperture exposing different area of vram. My interface change allow this easily, it also alow to support more advanced aperture handling if such things ever show up in the future. Thus i would like to keep my interface as it is and let the driver handle aperture io address and buffer move if necessary > > > However, in any case to avoid lock inversion between mmap_sem and > bo::reserve, one must ensure that any bo::reserve called during the > validation process (for example during eviction) is called with the > no_wait argument set to true, and if the call returns -EBUSY, call > set_need_resched() and return VM_FAULT_NOPAGE from fault. If the error > code is -ERESTARTSYS, we should also call VM_FAULT_NOPAGE, but without > the set_need_resched(). > This requires a return value from bo:driver::fault_reserve_notify and an > extra argument to ttm_bo_validate. Note that waiting for the GPU while > holding the mmap_sem is still OK from a lock inversion point of view, > which means that the @no_wait argument to ttm_bo_validate could still be > false. There might be other aspects to this, though. > > Note that this last section would have applied to your patch as well. > > /Thomas > I will update the first patch to do so. Cheers, Jerome ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
