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 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.