[Intel-gfx] [PATCH 3/4] dma-fence: Refactor signaling for manual invocation

Chris Wilson chris at chris-wilson.co.uk
Tue Aug 13 08:25:27 UTC 2019


Quoting Koenig, Christian (2019-08-13 07:59:28)
> Am 12.08.19 um 16:53 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:50:59)
> >> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2019-08-12 15:34:32)
> >>>> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> >>>>> Move the duplicated code within dma-fence.c into the header for wider
> >>>>> reuse. In the process apply a small micro-optimisation to only prune the
> >>>>> fence->cb_list once rather than use list_del on every entry.
> >>>>>
> >>>>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>>> ---
> >>>>>     drivers/dma-buf/Makefile                    |  10 +-
> >>>>>     drivers/dma-buf/dma-fence-trace.c           |  28 +++
> >>>>>     drivers/dma-buf/dma-fence.c                 |  33 +--
> >>>>>     drivers/gpu/drm/i915/gt/intel_breadcrumbs.c |  32 +--
> >>>>>     include/linux/dma-fence-impl.h              |  83 +++++++
> >>>>>     include/linux/dma-fence-types.h             | 258 ++++++++++++++++++++
> >>>>>     include/linux/dma-fence.h                   | 228 +----------------
> >>>> Mhm, I don't really see the value in creating more header files.
> >>>>
> >>>> Especially I'm pretty sure that the types should stay in dma-fence.h
> >>> iirc, when I included the trace.h from dma-fence.h or dma-fence-impl.h
> >>> without separating the types, amdgpu failed to compile (which is more
> >>> than likely to be simply due to be first drm in the list to compile).
> >> Ah, but why do you want to include trace.h in a header in the first place?
> >>
> >> That's usually not something I would recommend either.
> > The problem is that we do emit a tracepoint as part of the sequence I
> > want to put into the reusable chunk of code.
> 
> Ok, we are going in circles here. Why do you want to reuse the code then?

I am reusing the code to avoid fun and games with signal-vs-free.
-Chris


More information about the Intel-gfx mailing list