[PATCH 0/3] Deferr load of radeon/amdgpu until amdkfd is loaded

[Xinliang Liu]

On 23 February 2016 at 14:51, Oded Gabbay <oded.gabbay at gmail.com> wrote:
> On Tue, Feb 23, 2016 at 5:10 AM, Xinliang Liu <xinliang.liu at linaro.org> wrote:
>> On 15 February 2016 at 19:04, Oded Gabbay <oded.gabbay at gmail.com> wrote:
>>> On Sun, Feb 14, 2016 at 2:58 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>>> On Sun, Feb 14, 2016 at 11:16:52AM +0200, Oded Gabbay wrote:
>>>>> Following Daniel's request, I spent some time removing the hard requirement
>>>>> that radeon and amdgpu will always appear _after_ amdkfd in the drm Makefile.
>>>>>
>>>>> This was done by modifing radeon/amdgpu to defer their loading if they detect
>>>>> that amdkfd is not loaded yet, in case the drivers are built inside the
>>>>> kernel image.
>>>>>
>>>>> See the patch's individiual commit messages for more explanation.
>>>>>
>>>>> This patch-set was tested on a KAVERI machine, with multiple configurations:
>>>>>
>>>>> 1. radeon + amdgpu (CIK disabled) + amdkfd as kernel modules
>>>>> 2. radeon + amdgpu (CIK disabled) + amdkfd inside the kernel image
>>>>> 3. amdgpu (CIK enabled) + amdkfd inside the kernel image (radeon not compiled)
>>>>> 4. amdgpu (CIK enabled) inside the kernel image (radeon + amdkfd not compiled)
>>>>> 5. radeon + amdgpu (CIK disabled) as kernel modules (amdkfd not compiled)
>>>>
>>>> Care to throw one patch on top (maybe on top of the patch floating around)
>>>> to reorder amdkfd to be alphabetical? Just to make sure this doesn't get
>>>> broken again accidentally. Or maybe just pick up the other patch and adapt
>>>> it so it's all in one series.
>>>>
>>>> Thanks, Daniel
>>>
>>> Hi Daniel,
>>>
>>> I thought about it and I think I prefer to leave the current order as
>>> it is, for the reason that I observed the boot-up process is a little
>>> bit faster when the deferred probing doesn't occur. This is probably
>>> because all the moves between pending drivers list and active driver
>>> list.
>>>
>>> Although this patch-set ensure that the kernel will boot successfully
>>> with no regard to the order of amdkfd/radeon/amdgpu in the drm
>>
>> So, my drm make clean up patch should keep amdkfd in front of radeon/amdgpu?
>>
>> Best,
>> -xinliang
>
> As I wrote to Daniel, I think that for the sake of a faster boot time,
> we should keep amdkfd before radeon/amdgpu. This patch is to make sure
> that if someone will change it without us watching, everything will
> still work (and that's why its an important patch as Daniel said)
>

OK, got it.

> Oded
>
>>
>>> makefile, I think that if the current order gives us a bit less boot
>>> time then it is better to keep things as they are.
>>>
>>> Thanks,
>>>
>>>       Oded
>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>     Oded
>>>>>
>>>>> Oded Gabbay (3):
>>>>>   drm/amdkfd: Track when module's init is complete
>>>>>   drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded
>>>>>   drm/amdgpu: Return -EPROBE_DEFER when amdkfd not loaded
>>>>>
>>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c      | 57 +++++++++----------------
>>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h      |  2 +-
>>>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c         | 10 ++++-
>>>>>  drivers/gpu/drm/amd/amdkfd/kfd_module.c         | 15 +++++--
>>>>>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h |  2 +-
>>>>>  drivers/gpu/drm/radeon/radeon_drv.c             | 10 ++++-
>>>>>  drivers/gpu/drm/radeon/radeon_kfd.c             | 25 ++++++-----
>>>>>  drivers/gpu/drm/radeon/radeon_kfd.h             |  2 +-
>>>>>  8 files changed, 64 insertions(+), 59 deletions(-)
>>>>>
>>>>> --
>>>>> 2.5.0
>>>>>
>>>>
>>>> --
>>>> Daniel Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel