search for: ww_mutexes

...>> to the driver is ok, as long as they don't conflict with anything possible >> used by their own fence implementation. > Well that's almost what we have right now with the exception that > drivers are allowed (actually must for correctness when updating > fences) the ww_mutexes for dma-bufs (or other buffer objects). In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. But how does that then work right now? My impression was that it's mandatory for drivers to call fence_signaled()? &gt...

...driver is ok, as long as they don't conflict with anything possible >>> used by their own fence implementation. >> Well that's almost what we have right now with the exception that >> drivers are allowed (actually must for correctness when updating >> fences) the ww_mutexes for dma-bufs (or other buffer objects). > > In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. > > But how does that then work right now? My impression was that it's mandatory for drivers to call fence_...

...as they don't conflict with anything >>> possible >>> used by their own fence implementation. >> >> Well that's almost what we have right now with the exception that >> drivers are allowed (actually must for correctness when updating >> fences) the ww_mutexes for dma-bufs (or other buffer objects). > > > In this case sorry for so much noise. I really haven't looked in so much > detail into anything but Maarten's Radeon patches. > > But how does that then work right now? My impression was that it's mandatory > for drivers...

...n't conflict with anything >>>> possible >>>> used by their own fence implementation. >>> Well that's almost what we have right now with the exception that >>> drivers are allowed (actually must for correctness when updating >>> fences) the ww_mutexes for dma-bufs (or other buffer objects). >> >> In this case sorry for so much noise. I really haven't looked in so much >> detail into anything but Maarten's Radeon patches. >> >> But how does that then work right now? My impression was that it's mandatory &...

Am 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig > <deathsimple at vodafone.de> wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >> fence->signaled as well

...cking primitives local > to the driver is ok, as long as they don't conflict with anything possible > used by their own fence implementation. Well that's almost what we have right now with the exception that drivers are allowed (actually must for correctness when updating fences) the ww_mutexes for dma-bufs (or other buffer objects). Locking correctness is enforced with some extremely nasty lockdep annotations + additional debugging infrastructure enabled with CONFIG_DEBUG_WW_MUTEX_SLOWPATH. We really need to be able to hold dma-buf ww_mutexes while updating fences or waiting for them. An...

On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > The mgag200 driver requires this behavior for its cursor handling. The > patch also converts the driver to use the new interfaces. > > Signed-off-by: Thomas

On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > The mgag200 driver requires this behavior for its cursor handling. The > patch also converts the driver to use the new interfaces. > > Signed-off-by: Thomas

On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig <deathsimple at vodafone.de> wrote: >> Would that be something you can agree to? > > > No, the whole enable_signaling stuff should go away. No callback from the > driver into the fence code, only the other way around. > > fence->signaled as well as fence->wait should become mandatory and only > called from

...s long as they don't conflict with anything possible >>>> used by their own fence implementation. >>> Well that's almost what we have right now with the exception that >>> drivers are allowed (actually must for correctness when updating >>> fences) the ww_mutexes for dma-bufs (or other buffer objects). >> In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. >> >> But how does that then work right now? My impression was that it's mandatory for drivers to call...

Hi, > I think would be good to have a lockdep_assert_held here for the ww_mutex. > > Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations > we call the structure tracking the fences+lock the "reservation", but the > naming scheme used is _lock/_unlock. > > I think would be good to be consistent with that, and use _locked here. > Especially

Am 27.08.23 um 19:54 schrieb Dmitry Osipenko: > Add simple kref_put_dma_resv() helper that wraps around kref_put_ww_mutex() > for drivers that needs to lock dma-resv on kref_put(). > > It's not possible to easily add this helper to kref.h because of the > headers inclusion dependency, hence add it to dma-resv.h. I was never really a big fan of kref_put_mutex() in the first

Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: > > [SNIP] > I was thinking more of the general design of a base-class that needs > to be refcounted. Say a driver vm that inherits from gpu-vm, > gem_object and yet another base-class that supplies its own refcount. > What's the best-practice way to do refcounting? All base-classes > supplying a refcount of its own, or

Am 20.05.19 um 18:26 schrieb Daniel Vetter: > [CAUTION: External Email] > > On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote: >> On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: >>> The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the >>> GEM VRAM pin/unpin functions that do not reserve the BO during validation.

...on't conflict with anything possible >>>>> used by their own fence implementation. >>>> Well that's almost what we have right now with the exception that >>>> drivers are allowed (actually must for correctness when updating >>>> fences) the ww_mutexes for dma-bufs (or other buffer objects). >>> In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. >>> >>> But how does that then work right now? My impression was that it's mandatory for dri...

On 11/10/23 11:42, Christian K?nig wrote: > Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: >> >> [SNIP] > >> I was thinking more of the general design of a base-class that needs >> to be refcounted. Say a driver vm that inherits from gpu-vm, >> gem_object and yet another base-class that supplies its own refcount. >> What's the best-practice way to

On Mon, May 20, 2019 at 06:19:00PM +0200, Daniel Vetter wrote: > On Thu, May 16, 2019 at 06:27:45PM +0200, Thomas Zimmermann wrote: > > The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the > > GEM VRAM pin/unpin functions that do not reserve the BO during validation. > > The mgag200 driver requires this behavior for its cursor handling. The > >

...t with anything possible >>>>>> used by their own fence implementation. >>>>> Well that's almost what we have right now with the exception that >>>>> drivers are allowed (actually must for correctness when updating >>>>> fences) the ww_mutexes for dma-bufs (or other buffer objects). >>>> In this case sorry for so much noise. I really haven't looked in so much detail into anything but Maarten's Radeon patches. >>>> >>>> But how does that then work right now? My impression was that it's manda...

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]