From: "Tuikov, Luben" <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>
To: "Yin, Tianci (Rico)" <Tianci.Yin-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Deucher,
Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
"Koenig,
Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training
Date: Fri, 11 Oct 2019 23:23:44 +0000 [thread overview]
Message-ID: <9084e67e-adc2-b512-b593-ca218c17a366@amd.com> (raw)
In-Reply-To: <20191011035033.24935-7-tianci.yin-5C7GfCeVMHo@public.gmane.org>
On 2019-10-10 11:50 p.m., Tianci Yin wrote:
> From: "Tianci.Yin" <tianci.yin@amd.com>
>
> memory training using specific fixed vram segment, reserve these
> segments before anyone may allocate it.
>
> Change-Id: I1436755813a565608a2857a683f535377620a637
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Tianci.Yin <tianci.yin@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +++++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 9da6350a4ba2..42d0fcb98382 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1667,6 +1667,93 @@ static int amdgpu_ttm_fw_reserve_vram_init(struct amdgpu_device *adev)
> &adev->fw_vram_usage.va);
> }
>
> +/*
> + * Memoy training reservation functions
> + */
> +
> +/**
> + * amdgpu_ttm_training_reserve_vram_fini - free memory training reserved vram
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * free memory training reserved vram if it has been reserved.
> + */
> +static int amdgpu_ttm_training_reserve_vram_fini(struct amdgpu_device *adev)
> +{
> + struct psp_memory_training_context *ctx = &adev->psp.mem_train_ctx;
> +
> + ctx->init = PSP_MEM_TRAIN_NOT_SUPPORT;
> + if (ctx->c2p_bo) {
> + amdgpu_bo_free_kernel(&ctx->c2p_bo, NULL, NULL);
> + ctx->c2p_bo = NULL;
> + }
Generally it is a good idea to paragraph your code.
So an empty line between if-statements is a good idea.
However, there is no need in:
ret = f(x);
if (ret) {
<body of code>
}
if (blah) {
<body of code>
}
The above are two (2) well-formed paragraphs.
> + if (ctx->p2c_bo) {
> + amdgpu_bo_free_kernel(&ctx->p2c_bo, NULL, NULL);
> + ctx->p2c_bo = NULL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * amdgpu_ttm_training_reserve_vram_init - create bo vram reservation from memory training
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * create bo vram reservation from memory training.
> + */
> +static int amdgpu_ttm_training_reserve_vram_init(struct amdgpu_device *adev)
> +{
> + int ret;
> + struct psp_memory_training_context *ctx = &adev->psp.mem_train_ctx;
> +
> + memset(ctx, 0, sizeof(*ctx));
> + if (!adev->fw_vram_usage.mem_train_support) {
> + DRM_DEBUG("memory training does not support!\n");
> + return 0;
> + }
> +
> + ctx->c2p_train_data_offset = adev->fw_vram_usage.mem_train_fb_loc;
> + ctx->p2c_train_data_offset = (adev->gmc.mc_vram_size - GDDR6_MEM_TRAINING_OFFSET);
> + ctx->train_data_size = GDDR6_MEM_TRAINING_DATA_SIZE_IN_BYTES;
> +
> + DRM_DEBUG("train_data_size:%llx,p2c_train_data_offset:%llx,c2p_train_data_offset:%llx.\n",
> + ctx->train_data_size,
> + ctx->p2c_train_data_offset,
> + ctx->c2p_train_data_offset);
> +
> + ret = amdgpu_bo_create_kernel_at(adev,
> + ctx->p2c_train_data_offset,
> + ctx->train_data_size,
> + AMDGPU_GEM_DOMAIN_VRAM,
> + &ctx->p2c_bo,
> + NULL);
> + if (ret) {
> + DRM_ERROR("alloc p2c_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
NAK!
Why are you re-writing the error code from "amdgpu_bo_create_kenrel_at()"?
Pass the error as is.
> +
> + ret = amdgpu_bo_create_kernel_at(adev,
> + ctx->c2p_train_data_offset,
> + ctx->train_data_size,
> + AMDGPU_GEM_DOMAIN_VRAM,
> + &ctx->c2p_bo,
> + NULL);
> + if (ret) {
> + DRM_ERROR("alloc c2p_bo failed(%d)!\n", ret);
> + ret = -ENOMEM;
> + goto err_out;
> + }
NAK!
Why are you re-writing the error code from "amdgpu_bo_create_kenrel_at()"?
Pass the error as is.
> +
> + ctx->init = PSP_MEM_TRAIN_RESERVE_SUCCESS;
> + return 0;
> +
> +err_out:
Yes... well "err_out" could be any identifier, including
a variable, as our variables follow snake-notation, all lowercase.
Back at the turn of this century, Linux followed capitalized
goto labels to distinguish them from anything else around
in the kernel code:
goto Bad_err;
...
return 0;
Bad_err:
return bad_gift;
}
To distinguish that a capitalized identifier is a goto label,
"Bad_err" and all lower-case label is just another variable
or function identifier, "bad_gift".
Regards,
Luben
> + amdgpu_ttm_training_reserve_vram_fini(adev);
> + return ret;
> +}
> +
> /**
> * amdgpu_ttm_init - Init the memory management (ttm) as well as various
> * gtt/vram related fields.
> @@ -1740,6 +1827,14 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
> return r;
> }
>
> + /*
> + *The reserved vram for memory training must be pinned to the specified
> + *place on the VRAM, so reserve it early.
> + */
> + r = amdgpu_ttm_training_reserve_vram_init(adev);
> + if (r)
> + return r;
> +
> /* allocate memory as required for VGA
> * This is used for VGA emulation and pre-OS scanout buffers to
> * avoid display artifacts while transitioning between pre-OS
> @@ -1825,6 +1920,7 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
> return;
>
> amdgpu_ttm_debugfs_fini(adev);
> + amdgpu_ttm_training_reserve_vram_fini(adev);
> amdgpu_ttm_fw_reserve_vram_fini(adev);
> if (adev->mman.aper_base_kaddr)
> iounmap(adev->mman.aper_base_kaddr);
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-10-11 23:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 3:50 [PATCH 1/8] drm/amdgpu: update amdgpu_discovery to handle revision Tianci Yin
[not found] ` <20191011035033.24935-1-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 3:50 ` [PATCH 2/8] drm/amdgpu: add a generic fb accessing helper function Tianci Yin
[not found] ` <20191011035033.24935-2-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 22:44 ` Tuikov, Luben
2019-10-11 3:50 ` [PATCH 3/8] drm/amdgpu: introduce psp_v11_0_is_sos_alive interface Tianci Yin
2019-10-11 3:50 ` [PATCH 4/8] drm/amdgpu: update atomfirmware header with memory training related members Tianci Yin
[not found] ` <20191011035033.24935-4-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 22:53 ` Tuikov, Luben
[not found] ` <155db3ea-82ba-e3d7-8e2f-96df99772871-5C7GfCeVMHo@public.gmane.org>
2019-10-12 2:21 ` Alex Deucher
2019-10-11 3:50 ` [PATCH 5/8] drm/amdgpu/atomfirmware: add memory training related helper functions Tianci Yin
[not found] ` <20191011035033.24935-5-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 23:09 ` Tuikov, Luben
2019-10-11 3:50 ` [PATCH 6/8] drm/amdgpu: add psp memory training callbacks and macro Tianci Yin
2019-10-11 3:50 ` [PATCH 7/8] drm/amdgpu: reserve vram for memory training Tianci Yin
[not found] ` <20191011035033.24935-7-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 23:23 ` Tuikov, Luben [this message]
[not found] ` <9084e67e-adc2-b512-b593-ca218c17a366-5C7GfCeVMHo@public.gmane.org>
2019-10-12 2:26 ` Alex Deucher
2019-10-14 8:26 ` Koenig, Christian
[not found] ` <a93b3b8e-4df9-f6e2-95f7-3f0c0d8bebdc-5C7GfCeVMHo@public.gmane.org>
2019-10-14 8:35 ` Yin, Tianci (Rico)
2019-10-11 3:50 ` [PATCH 8/8] drm/amdgpu/psp: add psp memory training implementation Tianci Yin
[not found] ` <20191011035033.24935-8-tianci.yin-5C7GfCeVMHo@public.gmane.org>
2019-10-11 23:44 ` Tuikov, Luben
-- strict thread matches above, loose matches on Subject: below --
2019-10-08 19:29 [PATCH 0/8] low latency memory training for navi Alex Deucher
[not found] ` <20191008192934.5481-1-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-08 19:29 ` [PATCH 7/8] drm/amdgpu: reserve vram for memory training Alex Deucher
[not found] ` <20191008192934.5481-8-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-09 3:44 ` Tuikov, Luben
[not found] ` <a9d04519-0ec0-41f6-289f-be156caccf76-5C7GfCeVMHo@public.gmane.org>
2019-10-09 11:12 ` Yin, Tianci (Rico)
[not found] ` <SN1PR12MB2544F1BE7D37DEC4721AF95D95950-z7L1TMIYDg7bG+2ccTdVRgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-10-09 11:40 ` Christian König
[not found] ` <045b7cfd-989f-7cff-310f-92d9780e73fe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-10-09 11:50 ` Yin, Tianci (Rico)
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=9084e67e-adc2-b512-b593-ca218c17a366@amd.com \
--to=luben.tuikov-5c7gfcevmho@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
--cc=Tianci.Yin-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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