[PATCH 3/4] dma-fence: Refactor signaling for manual invocation
Koenig, Christian
Christian.Koenig at amd.com
Tue Aug 13 06:59:28 UTC 2019
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?
Christian.
> -Chris
More information about the dri-devel
mailing list