dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2 13/15] drm/ttm: Add BO and offset arguments for vm_access and vm_fault ttm handlers.
Date: Tue, 18 May 2021 19:10:39 +0200	[thread overview]
Message-ID: <a924457e-321e-9f16-82c8-2462c2ae7043@linux.intel.com> (raw)
In-Reply-To: <01128dfc-fb5f-6247-9feb-9cd05586d790@amd.com>


On 5/18/21 5:29 PM, Christian König wrote:
>
>
> Am 18.05.21 um 17:25 schrieb Thomas Hellström:
>>
>> On 5/18/21 5:17 PM, Christian König wrote:
>>>
>>>
>>> Am 18.05.21 um 17:11 schrieb Thomas Hellström:
>>>>
>>>> On 5/18/21 5:07 PM, Christian König wrote:
>>>>> Am 18.05.21 um 16:55 schrieb Thomas Hellström:
>>>>>> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>>>>>>
>>>>>> This allows other drivers that may not setup the vma in the same way
>>>>>> to use the ttm bo helpers.
>>>>>
>>>>> Uff can you please explain why exactly you need that?
>>>>>
>>>>> Providing the BO is not much of a problem, but having the BO at 
>>>>> different VMA offsets is really a no-go with TTM.
>>>>>
>>>>> Christian.
>>>>
>>>> The current i915 uapi is using different offsets for different 
>>>> caching :/. We're currently working around that by using 
>>>> ttm_bo_type_kernel (no TTM vma offset at all) and i915's offset.
>>>
>>> Can you instead adjust the offset in the mmap callback like we do 
>>> for dma-buf?
>> Will have to take a look.
>>>
>>> That's really a no-go what you describe here because it will mess up 
>>> reverse mapping lockup for buffer movement.
>>
>> You mean the unmap_mapping_range() stuff? That's not a problem since 
>> it's a NOP for kernel ttm buffers, and the i915 move() / 
>> swap_notify() takes care of killing the ptes.
>
> That design is a certain NAK from my side for upstreaming this.
>
> PTE handling is the domain of TTM, drivers should never mess with that 
> directly.

Hmm. May I humbly suggest a different view on this:

I agree fully for ttm_bo_type_device bos but for ttm_bo_type_kernel, TTM 
has no business whatsoever with user-space PTEs. That's really why that 
bo type exists in the first place. But otoh one can of course argue that 
then i915 has no business calling the TTM fault helper for these bos.

So for discrete we can probably do the right thing with 
ttm_bo_type_device. What worries me a bit is when we get to older 
hardware support because whatever we do is by definition going to be 
ugly. At best we might be able to split the address space between i915's 
mmos, and hand the rest to TTM, modifying offsets as you suggest. That 
way a TTM call to unmap_mapping_range() would do the right thing, I think.

/Thomas

>
> Christian.
>
>>
>> While we're in the process of killing that offset flexibility for 
>> discrete, we can't do so for older hardware unfortunately.
>>
>> /Thomas
>>
>>
>>>
>>> Christian.
>>
>>
>>
>>>
>>>>
>>>> /Thomas
>>>>
>>>
>

  reply	other threads:[~2021-05-18 17:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210518145543.1042429-1-thomas.hellstrom@linux.intel.com>
2021-05-18 15:07 ` [PATCH v2 13/15] drm/ttm: Add BO and offset arguments for vm_access and vm_fault ttm handlers Christian König
2021-05-18 15:11   ` Thomas Hellström
2021-05-18 15:17     ` Christian König
2021-05-18 15:25       ` Thomas Hellström
2021-05-18 15:29         ` Christian König
2021-05-18 17:10           ` Thomas Hellström [this message]
2021-05-18 17:17             ` Christian König
2021-05-18 17:32               ` Thomas Hellström
2021-05-18 18:11                 ` Christian König
2021-05-18 16:49   ` Maarten Lankhorst
2021-05-18 17:06     ` Christian König
2021-05-18  8:26 [PATCH v2 00/15] drm/i915: Move LMEM (VRAM) management over to TTM Thomas Hellström
2021-05-18  8:26 ` [PATCH v2 13/15] drm/ttm: Add BO and offset arguments for vm_access and vm_fault ttm handlers Thomas Hellström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a924457e-321e-9f16-82c8-2462c2ae7043@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox