On 08.10.25 09:34, Tvrtko Ursulin wrote:
>
> On 07/10/2025 16:04, Christian König wrote:
>> On 07.10.25 16:27, Tvrtko Ursulin wrote:
>>>
>>>
>>> On 07/10/2025 15:03, Christian König wrote:
>>>> On 07.10.25 16:00, Tvrtko Ursulin wrote:
>>>>>>
>>>>>> Please not in the header. Neither drivers nor other TTM modules should
>>>>>> mess with such properties.
>>>>>>
>>>>>> That is all internal to the pool.
>>>>>
>>>>> Hmm IMHO it is not that bad. Especially that ttm_pool.c and ttm_tt.c need
>>>>> to have access to them. Alternatiev is a new header for internal helpers
>>>>> which sounds a bit too much. But if you insist I can create it.
>>>>
>>>> Wait a second why is ttm_tt.c still needing this? For the DMA32 eviction?
>>>
>>> Apparently so, goes back to:
>>>
>>> 680dcede2762 ("drm/ttm: switch back to static allocation limits for now"
>>>
>>> Then there is the newer usage for ttm->use_dma_alloc from:
>>>
>>> 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when
>>> needed")
>>
>> Ah yes that was the DMA layer hack for encryption Zack came up with.
>>
>> In this case please put the functions into ttm_bo_internal.h. It should
>> already be in the ttm directory for TTM internal stuff.
>
> Then ttm_pool.c will have to start including ttm_bo_internal.h which feels it
> is making the component separation worse. Add ttm_pool_internal.h? Keep in
> ttm_pool.h?
In that case just add ttm_pool_internal.h.
Thanks,
Christian.
>
> Regards,
>
> Tvrtko
>
>>
>> Going to comment on the other patch as well.
>>
>> Thanks,
>> Christian.
>>
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>
>
