From: "Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Yin, Tianci (Rico)" <Tianci.Yin-5C7GfCeVMHo@public.gmane.org>,
"Tuikov, Luben" <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>,
Alex Deucher
<alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training
Date: Wed, 9 Oct 2019 13:40:33 +0200 [thread overview]
Message-ID: <045b7cfd-989f-7cff-310f-92d9780e73fe@gmail.com> (raw)
In-Reply-To: <SN1PR12MB2544F1BE7D37DEC4721AF95D95950-z7L1TMIYDg7bG+2ccTdVRgdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 7068 bytes --]
Am 09.10.19 um 13:12 schrieb Yin, Tianci (Rico):
> Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
> just to avoid "pesky compiler unininitialized variable warnings"--those
> are helpful to make the code more secure: a variable should be
> intentionally
> initialized in all paths.
>
> Rico: Still in confusion, pre-initialization can avoid "uninitialized
> variable", why should we can't pre-initialize?
Because it avoids the uninitialized variable warning :)
See we really want the warning because it means that we have a bug in
the code somewhere.
Regards,
Christian.
> ------------------------------------------------------------------------
> *From:* Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>
> *Sent:* Wednesday, October 9, 2019 11:44
> *To:* Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>;
> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
> *Cc:* Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>; Yin, Tianci
> (Rico) <Tianci.Yin-5C7GfCeVMHo@public.gmane.org>
> *Subject:* Re: [PATCH 7/8] drm/amdgpu: reserve vram for memory training
> On 2019-10-08 3:29 p.m., Alex Deucher wrote:
> > From: "Tianci.Yin" <tianci.yin-5C7GfCeVMHo@public.gmane.org>
> >
> > memory training using specific fixed vram segment, reserve these
> > segments before anyone may allocate it.
> >
> > Change-Id: I1436755813a565608a2857a683f535377620a637
> > Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>
> > Signed-off-by: Tianci.Yin <tianci.yin-5C7GfCeVMHo@public.gmane.org>
> > ---
> > 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 74a9bd94f10c..0819721af16e 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
> > + */
>
> Include an empty line between the two comments, just as you would
> a paragraph in written text.
>
> > +/**
> > + * 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)
> > +{
> > + int ret = 0;
> > + struct psp_memory_training_context *ctx =
> &adev->psp.mem_train_ctx;
> > +
> > + ctx->init = PSP_MEM_TRAIN_NOT_SUPPORT;
> > + if(ctx->c2p_bo) {
>
> Space after keywords, according to LKCS:
> if (...)
>
> > + amdgpu_bo_free_kernel(&ctx->c2p_bo, NULL, NULL);
> > + ctx->c2p_bo = NULL;
> > + }
> > + if(ctx->p2c_bo) {
>
> Space after keywords, according to LKCS:
> if (...)
>
> > + amdgpu_bo_free_kernel(&ctx->p2c_bo, NULL, NULL);
> > + ctx->p2c_bo = NULL;
> > + }
> > +
> > + return ret;
> > +}
>
> Get rid of "ret" variable altogether as it is not used in this function.
>
> > +
> > +/**
> > + * 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 = 0;
>
> DO NOT preinitialize 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) {
>
> Space after keywords: "if (".
>
> > + 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,
>
> Here is where you definitively set "ret" so DO NOT preinitialize it to 0,
> just to avoid "pesky compiler unininitialized variable warnings"--those
> are helpful to make the code more secure: a variable should be
> intentionally
> initialized in all paths.
>
> > + ctx->p2c_train_data_offset,
> > + ctx->train_data_size,
> > + AMDGPU_GEM_DOMAIN_VRAM,
> > + &ctx->p2c_bo,
> > + NULL);
> > + if(ret) {
>
> Space after keywords "if (".
>
> > + DRM_ERROR("alloc p2c_bo failed(%d)!\n", ret);
> > + ret = -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + 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) {
>
> Space after keywords: "if (", according to LKCS.
>
> Regards,
> Luben
>
> > + DRM_ERROR("alloc c2p_bo failed(%d)!\n", ret);
> > + ret = -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + ctx->init = PSP_MEM_TRAIN_RESERVE_SUCCESS;
> > + return 0;
> > +
> > +err_out:
> > + 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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 14798 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
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-09 11:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
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 1/8] drm/amdgpu: update amdgpu_discovery to handle revision Alex Deucher
2019-10-08 19:29 ` [PATCH 2/8] drm/amdgpu: add a generic fb accessing helper function Alex Deucher
[not found] ` <20191008192934.5481-3-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-09 8:25 ` Christian König
[not found] ` <0edeab78-992c-89b2-f2c2-41db101bc5b7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-10-09 11:30 ` Yin, Tianci (Rico)
2019-10-08 19:29 ` [PATCH 3/8] drm/amdgpu: introduce psp_v11_0_is_sos_alive interface Alex Deucher
[not found] ` <20191008192934.5481-4-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-09 3:21 ` Tuikov, Luben
2019-10-08 19:29 ` [PATCH 4/8] drm/amdgpu: update atomfirmware header with memory training related members Alex Deucher
[not found] ` <20191008192934.5481-5-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-08 20:25 ` William Lewis
2019-10-09 3:26 ` Tuikov, Luben
2019-10-08 19:29 ` [PATCH 5/8] drm/amdgpu/atomfirmware: add memory training related helper functions Alex Deucher
[not found] ` <20191008192934.5481-6-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-09 3:34 ` Tuikov, Luben
2019-10-08 19:29 ` [PATCH 6/8] drm/amdgpu: add psp memory training callbacks and macro Alex Deucher
[not found] ` <20191008192934.5481-7-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-08 20:27 ` William Lewis
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 [this message]
[not found] ` <045b7cfd-989f-7cff-310f-92d9780e73fe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-10-09 11:50 ` Yin, Tianci (Rico)
2019-10-08 19:29 ` [PATCH 8/8] drm/amdgpu/psp: add psp memory training implementation Alex Deucher
[not found] ` <20191008192934.5481-9-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2019-10-09 4:04 ` Tuikov, Luben
-- strict thread matches above, loose matches on Subject: below --
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 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
[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)
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=045b7cfd-989f-7cff-310f-92d9780e73fe@gmail.com \
--to=ckoenig.leichtzumerken-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=Luben.Tuikov-5C7GfCeVMHo@public.gmane.org \
--cc=Tianci.Yin-5C7GfCeVMHo@public.gmane.org \
--cc=alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@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