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 17:25:14 +0200 [thread overview]
Message-ID: <07c9239c-1d72-26d8-4fe3-378bf826bae2@linux.intel.com> (raw)
In-Reply-To: <151faa7d-c4c0-4f8b-f127-9e82a5432774@amd.com>
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.
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
>>
>
next prev parent reply other threads:[~2021-05-18 15:25 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 [this message]
2021-05-18 15:29 ` Christian König
2021-05-18 17:10 ` Thomas Hellström
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=07c9239c-1d72-26d8-4fe3-378bf826bae2@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