> 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 at 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 at 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 at 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");
>>>>>
