All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Sierra Guiza, Alejandro (Alex)" <Alex.Sierra@amd.com>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"Kuehling, Felix" <Felix.Kuehling@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/5] drm/amdgpu: export function to flush TLB via pasid
Date: Tue, 7 Jan 2020 13:37:43 +0100	[thread overview]
Message-ID: <63eb205e-e682-e640-8316-ce64d762deae@gmail.com> (raw)
In-Reply-To: <BN7PR12MB2610CC53C630F7ABD8B95018FD3F0@BN7PR12MB2610.namprd12.prod.outlook.com>

Am 07.01.20 um 02:09 schrieb Sierra Guiza, Alejandro (Alex):
> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig@amd.com>
> Sent: Monday, January 6, 2020 10:23 AM
> To: Kuehling, Felix <Felix.Kuehling@amd.com>; amd-gfx@lists.freedesktop.org; Sierra Guiza, Alejandro (Alex) <Alex.Sierra@amd.com>
> Subject: Re: [PATCH 2/5] drm/amdgpu: export function to flush TLB via pasid
>
> Am 06.01.20 um 17:04 schrieb Felix Kuehling:
>> On 2020-01-05 10:41 a.m., Christian König wrote:
>>> Am 20.12.19 um 07:24 schrieb Alex Sierra:
>>>> This can be used directly from amdgpu and amdkfd to invalidate TLB
>>>> through pasid.
>>>> It supports gmc v7, v8, v9 and v10.
>>>>
>>>> Change-Id: I6563a8eba2e42d1a67fa2547156c20da41d1e490
>>>> Signed-off-by: Alex Sierra <alex.sierra@amd.com>
>>>> ---
>>>>    drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h |  6 ++
>>>>    drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c  | 81
>>>> ++++++++++++++++++++++++
>>>>    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 33 ++++++++++
>>>>    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 34 ++++++++++
>>>>    drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 84
>>>> +++++++++++++++++++++++++
>>>>    5 files changed, 238 insertions(+)
>> [snip]
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>> index fa025ceeea0f..eb1e64bd56ed 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
>>>> @@ -38,10 +38,12 @@
>>>>    #include "dce/dce_12_0_sh_mask.h"
>>>>    #include "vega10_enum.h"
>>>>    #include "mmhub/mmhub_1_0_offset.h"
>>>> +#include "athub/athub_1_0_sh_mask.h"
>>>>    #include "athub/athub_1_0_offset.h"
>>>>    #include "oss/osssys_4_0_offset.h"
>>>>      #include "soc15.h"
>>>> +#include "soc15d.h"
>>>>    #include "soc15_common.h"
>>>>    #include "umc/umc_6_0_sh_mask.h"
>>>>    @@ -434,6 +436,47 @@ static bool
>>>> gmc_v9_0_use_invalidate_semaphore(struct amdgpu_device *adev,
>>>>               adev->pdev->device == 0x15d8)));
>>>>    }
>>>>    +static bool gmc_v9_0_get_atc_vmid_pasid_mapping_info(struct
>>>> amdgpu_device *adev,
>>>> +                    uint8_t vmid, uint16_t *p_pasid) {
>>>> +    uint32_t value;
>>>> +
>>>> +    value = RREG32(SOC15_REG_OFFSET(ATHUB, 0,
>>>> mmATC_VMID0_PASID_MAPPING)
>>>> +             + vmid);
>>>> +    *p_pasid = value & ATC_VMID0_PASID_MAPPING__PASID_MASK;
>>>> +
>>>> +    return !!(value & ATC_VMID0_PASID_MAPPING__VALID_MASK);
>>>> +}
>>> Probably better to expose just this function in the GMC interface.
>> This is called below in gmc_v9_0_flush_gpu_tlb_pasid in the case that
>> the KIQ is not ready. It is not needed outside this file, so no need
>> to expose it in the GMC interface.
>>
>>
>>>> +
>>>> +static int gmc_v9_0_invalidate_tlbs_with_kiq(struct amdgpu_device
>>>> *adev,
>>>> +                uint16_t pasid, uint32_t flush_type,
>>>> +                bool all_hub)
>>>> +{
>>>> +    signed long r;
>>>> +    uint32_t seq;
>>>> +    struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
>>>> +
>>>> +    spin_lock(&adev->gfx.kiq.ring_lock);
>>>> +    amdgpu_ring_alloc(ring, 12); /* fence + invalidate_tlbs
>>>> +package*/
>>>> +    amdgpu_ring_write(ring, PACKET3(PACKET3_INVALIDATE_TLBS, 0));
>>>> +    amdgpu_ring_write(ring,
>>>> +            PACKET3_INVALIDATE_TLBS_DST_SEL(1) |
>>>> +            PACKET3_INVALIDATE_TLBS_ALL_HUB(all_hub) |
>>>> +            PACKET3_INVALIDATE_TLBS_PASID(pasid) |
>>>> +            PACKET3_INVALIDATE_TLBS_FLUSH_TYPE(flush_type));
>>>> That stuff is completely unrelated to the GMC and shouldn't be added
>>>> here.
>>> Where else should it go? To me TLB flushing is very much something
>>> that belongs in this file.
>>>
>>> Maybe you'd rather add "flush_tlbs_with_kiq" to amdgpu_ring_funcs and
>>> implement it in the gfx_v*.c GFX-IP code? I'm not sure that makes much
>>> sense either because it's only available on the KIQ ring.
>> Yes, something like this. We should probably add a amdgpu_kiq_funcs and expose the functions needed by the GMC code there.
>> See the amdgpu_virt_kiq_reg_write_reg_wait() case for reference, it is very similar and should probably be added to that function table as well.
>> Christian.
> To summarize:
> 1.- The idea is to add a new function pointer to the amdgpu_ring_funcs to flush the tlbs with kiq.

I would add a new amdgpu_kiq_funcs structure for that.

> 2.- This function pointer should be pointed and implemented on each of the gfx_v*.c under the gfx_*_ring_funcs_kiq struct. If this is true, Im not seeing this struct on the gfx_v10.c file.
> 3.- Use the amdgpu_virt_kiq_reg_write_reg_wait as a reference for the implementation.

Well yes and no, the amdgpu_virt_kiq_reg_write_reg_wait() was just an 
example of a similar case.

The function amdgpu_virt_kiq_reg_write_reg_wait() should probably be 
cleaned up and moved into the gfx_*.c files as well.

Regards,
Christian.

>
>>>
>>>> Christian.
>>>>
>>>> +    amdgpu_fence_emit_polling(ring, &seq);
>>>> +    amdgpu_ring_commit(ring);
>>>> +    spin_unlock(&adev->gfx.kiq.ring_lock);
>>>> +
>>>> +    r = amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout);
>>>> +    if (r < 1) {
>>>> +        DRM_ERROR("wait for kiq fence error: %ld.\n", r);
>>>> +        return -ETIME;
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +}
>>>> +
>>>>    /*
>>>>     * GART
>>>>     * VMID 0 is the physical GPU addresses as used by the kernel.
>>>> @@ -532,6 +575,46 @@ static void gmc_v9_0_flush_gpu_tlb(struct
>>>> amdgpu_device *adev, uint32_t vmid,
>>>>        DRM_ERROR("Timeout waiting for VM flush ACK!\n");
>>>>    }
>>>>    +/**
>>>> + * gmc_v9_0_flush_gpu_tlb_pasid - tlb flush via pasid
>>>> + *
>>>> + * @adev: amdgpu_device pointer
>>>> + * @pasid: pasid to be flush
>>>> + *
>>>> + * Flush the TLB for the requested pasid.
>>>> + */
>>>> +static int gmc_v9_0_flush_gpu_tlb_pasid(struct amdgpu_device *adev,
>>>> +                    uint16_t pasid, uint32_t flush_type,
>>>> +                    bool all_hub)
>> Christian, do you agree that this function belongs in the GMC
>> interface? If not here, where do you suggest moving it?
>>
>> Regards,
>>    Felix
>>
>>
>>>> +{
>>>> +    int vmid, i;
>>>> +    uint16_t queried_pasid;
>>>> +    bool ret;
>>>> +    struct amdgpu_ring *ring = &adev->gfx.kiq.ring;
>>>> +
>>>> +    if (adev->in_gpu_reset)
>>>> +        return -EIO;
>>>> +
>>>> +    if (ring->sched.ready)
>>>> +        return gmc_v9_0_invalidate_tlbs_with_kiq(adev,
>>>> +                        pasid, flush_type, all_hub);
>>>> +
>>>> +    for (vmid = 1; vmid < 16; vmid++) {
>>>> +
>>>> +        ret = gmc_v9_0_get_atc_vmid_pasid_mapping_info(adev, vmid,
>>>> +                &queried_pasid);
>>>> +        if (ret && queried_pasid == pasid) {
>>>> +            for (i = 0; i < adev->num_vmhubs; i++)
>>>> +                amdgpu_gmc_flush_gpu_tlb(adev, vmid,
>>>> +                            i, flush_type);
>>>> +            break;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    return 0;
>>>> +
>>>> +}
>>>> +
>>>>    static uint64_t gmc_v9_0_emit_flush_gpu_tlb(struct amdgpu_ring
>>>> *ring,
>>>>                            unsigned vmid, uint64_t pd_addr)
>>>>    {
>>>> @@ -693,6 +776,7 @@ static void gmc_v9_0_get_vm_pte(struct
>>>> amdgpu_device *adev,
>>>>      static const struct amdgpu_gmc_funcs gmc_v9_0_gmc_funcs = {
>>>>        .flush_gpu_tlb = gmc_v9_0_flush_gpu_tlb,
>>>> +    .flush_gpu_tlb_pasid = gmc_v9_0_flush_gpu_tlb_pasid,
>>>>        .emit_flush_gpu_tlb = gmc_v9_0_emit_flush_gpu_tlb,
>>>>        .emit_pasid_mapping = gmc_v9_0_emit_pasid_mapping,
>>>>        .map_mtype = gmc_v9_0_map_mtype,
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx@lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>>> ts.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&amp;data=02%7C01%7C
>>> felix.kuehling%40amd.com%7C0ebb82d62d1044ea57b608d791f5b021%7C3dd8961
>>> fe4884e608e11a82d994e183d%7C0%7C0%7C637138356784407460&amp;sdata=K8zh
>>> HT2YYFj8LXdD3YiihtNkbKNwa0ml6nQZ74zF828%3D&amp;reserved=0
>>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2020-01-07 12:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20  6:24 [PATCH 1/5] drm/amdgpu: Avoid reclaim fs while eviction lock Alex Sierra
2019-12-20  6:24 ` [PATCH 2/5] drm/amdgpu: export function to flush TLB via pasid Alex Sierra
2019-12-20 21:32   ` Felix Kuehling
2019-12-20 23:51   ` Yong Zhao
2020-01-05 15:41   ` Christian König
2020-01-06 16:04     ` Felix Kuehling
2020-01-06 16:23       ` Christian König
2020-01-07  1:09         ` Sierra Guiza, Alejandro (Alex)
2020-01-07 12:37           ` Christian König [this message]
2019-12-20  6:24 ` [PATCH 3/5] drm/amdgpu: GPU TLB flush API moved to amdgpu_amdkfd Alex Sierra
2019-12-20 21:35   ` Felix Kuehling
2019-12-20 23:50     ` Yong Zhao
2019-12-21  0:01       ` Yong Zhao
2019-12-23 19:34         ` Felix Kuehling
2019-12-23 19:44           ` Zhao, Yong
2019-12-20  6:24 ` [PATCH 4/5] drm/amdgpu: flush TLB functions removal from kfd2kgd interface Alex Sierra
2019-12-20 21:38   ` Felix Kuehling
2019-12-20  6:24 ` [PATCH 5/5] drm/amdgpu: invalidate BO during userptr mapping Alex Sierra
2019-12-20 21:40   ` Felix Kuehling
2019-12-20 21:39 ` [PATCH 1/5] drm/amdgpu: Avoid reclaim fs while eviction lock Felix Kuehling
2019-12-20 23:28 ` Yong Zhao
2020-01-02  9:16 ` Christian König
  -- strict thread matches above, loose matches on Subject: below --
2020-01-02 21:11 Alex Sierra
2020-01-02 21:11 ` [PATCH 2/5] drm/amdgpu: export function to flush TLB via pasid Alex Sierra
2020-01-02 21:31   ` Yong Zhao

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=63eb205e-e682-e640-8316-ce64d762deae@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=Alex.Sierra@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=amd-gfx@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.