From: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
To: "Ding, Pixel" <Pixel.Ding-5C7GfCeVMHo@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Cc: "Ding.Pixel-5C7GfCeVMHo@public.gmane.org"
<Ding.Pixel-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 1/2] drm/amdgpu: don't clean the framebuffer for VF
Date: Tue, 7 Feb 2017 12:05:03 +0100 [thread overview]
Message-ID: <b2dff7ca-4de5-3c52-63ba-86cc4e7c66cc@amd.com> (raw)
In-Reply-To: <F12BF8F4-A6D3-4685-A8C8-0D610706836D-5C7GfCeVMHo@public.gmane.org>
> I think you mean loading KMS multiple times by “reuse”.
No, as far as I know the fb emulation can be initialized multiple times
without driver reload.
> I can’t see a case that fb_probe is invoked out of loading KMS, is there?
I'm not so deeply into this, but I knew that you can certainly unbind
and bind again an fb while the driver is still loaded.
I simply assumed that the create function is then called multiple times.
> If I remove memset_io here and add GPU clear flag, should it be common logic or specific for VF?
That should be generic and work for all cases. Using the clear flag just
lets the GPU clear the memory in the background.
Regards,
Christian.
Am 07.02.2017 um 02:37 schrieb Ding, Pixel:
> Hi Christian,
>
> I think you mean loading KMS multiple times by “reuse”. At every time loading KMS, guest driver tells the host to clear FB during early init. I can’t see a case that fb_probe is invoked out of loading KMS, is there?
>
> Anyway I understand we don’t want to have many SRIOV conditional code paths. If I remove memset_io here and add GPU clear flag, should it be common logic or specific for VF?
>
> —
> Sincerely Yours,
> Pixel
>
>
>
>
>
>
>
> On 06/02/2017, 5:17 PM, "Koenig, Christian" <Christian.Koenig@amd.com> wrote:
>
>> Hi Pixel,
>>
>> you don't seem to understand the reason for the clear here.
>>
>> It is completely irrelevant that the host is clearing the memory for the
>> guest, the problem is that the guest reuse the memory it got assigned
> >from the host multiple times.
>> IIRC we added this because you could see leftovers of the slash screen
>> in the text console when the resolution wasn't a multiple of the
>> character height.
>>
>> Regards,
>> Christian.
>>
>> Am 06.02.2017 um 10:09 schrieb Ding, Pixel:
>>> Hi Christian,
>>>
>>> The underlying host driver clears VF’s framebuffer when guest driver shake hands with it, that is done before guest driver init. I think it’s unnecessary to clear FB again even with GPU for VF.
>>>
>>> —
>>> Sincerely Yours,
>>> Pixel
>>>
>>>
>>>
>>>
>>>
>>> On 06/02/2017, 4:49 PM, "Koenig, Christian" <Christian.Koenig@amd.com> wrote:
>>>
>>>> Am 06.02.2017 um 07:24 schrieb Pixel Ding:
>>>>> The SRIOV host driver cleans framebuffer for each VF, guest driver
>>>>> needn't this action which costs much time on some virtualization
>>>>> platform, otherwise it might get timeout to initialize.
>>>>>
>>>>> Signed-off-by: Pixel Ding <Pixel.Ding@amd.com>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>>>> index 1e735c4..f1eb4f5 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
>>>>> @@ -242,7 +242,9 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
>>>>> /* setup helper */
>>>>> rfbdev->helper.fb = fb;
>>>>>
>>>>> - memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
>>>>> + if (!amdgpu_sriov_vf(adev)) {
>>>>> + memset_io(abo->kptr, 0x0, amdgpu_bo_size(abo));
>>>>> + }
>>>> Nit pick only, but coding style says to not use "{" "}" in an if without
>>>> else and only a single line of code.
>>>>
>>>> Additional to that I'm not sure if that's a good idea. The memory
>>>> allocated here might be already be used and so we need to clear it no
>>>> matter where it came from.
>>>>
>>>> It's probably easier to just set the AMDGPU_GEM_CREATE_VRAM_CLEARED in
>>>> the call to amdgpu_gem_object_create(). This makes the GPU clear the
>>>> memory before the first CPU access to it.
>>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>>
>>>>> strcpy(info->fix.id, "amdgpudrmfb");
>>>>>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prev parent reply other threads:[~2017-02-07 11:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-06 6:24 [PATCH 1/2] drm/amdgpu: don't clean the framebuffer for VF Pixel Ding
[not found] ` <1486362299-3961-1-git-send-email-Pixel.Ding-5C7GfCeVMHo@public.gmane.org>
2017-02-06 7:21 ` Yu, Xiangliang
2017-02-06 8:49 ` Christian König
[not found] ` <9fb90cdc-60e4-babf-e721-10434ffda956-5C7GfCeVMHo@public.gmane.org>
2017-02-06 9:09 ` Ding, Pixel
[not found] ` <33AD6DBD-DC84-40FC-9CDF-02A18620F06C-5C7GfCeVMHo@public.gmane.org>
2017-02-06 9:17 ` Christian König
[not found] ` <31b35028-f22e-7e59-bcbc-3f6ae85f8d9f-5C7GfCeVMHo@public.gmane.org>
2017-02-06 9:26 ` Ding, Pixel
2017-02-07 1:37 ` Ding, Pixel
[not found] ` <F12BF8F4-A6D3-4685-A8C8-0D610706836D-5C7GfCeVMHo@public.gmane.org>
2017-02-07 11:05 ` Christian König [this message]
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=b2dff7ca-4de5-3c52-63ba-86cc4e7c66cc@amd.com \
--to=christian.koenig-5c7gfcevmho@public.gmane.org \
--cc=Ding.Pixel-5C7GfCeVMHo@public.gmane.org \
--cc=Pixel.Ding-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 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.