On 28.10.2024 11:52 AM, Dmitry Baryshkov wrote: > On Mon, Oct 28, 2024 at 11:36:15AM +0100, Konrad Dybcio wrote: >> On 28.10.2024 11:27 AM, Dmitry Baryshkov wrote: >>> On Mon, 28 Oct 2024 at 12:08, Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> wrote: >>>> >>>> On 10/28/2024 1:56 PM, Dmitry Baryshkov wrote: >>>>> On Sun, Oct 27, 2024 at 11:35:47PM +0530, Akhil P Oommen wrote: >>>>>> Clang-19 and above sometimes end up with multiple copies of the large >>>>>> a6xx_hfi_msg_bw_table structure on the stack. The problem is that >>>>>> a6xx_hfi_send_bw_table() calls a number of device specific functions to >>>>>> fill the structure, but these create another copy of the structure on >>>>>> the stack which gets copied to the first. >>>>>> >>>>>> If the functions get inlined, that busts the warning limit: >>>>>> >>>>>> drivers/gpu/drm/msm/adreno/a6xx_hfi.c:631:12: error: stack frame size (1032) exceeds limit (1024) in 'a6xx_hfi_send_bw_table' [-Werror,-Wframe-larger-than] >>>>>> >>>>>> Fix this by kmalloc-ating struct a6xx_hfi_msg_bw_table instead of using >>>>>> the stack. Also, use this opportunity to skip re-initializing this table >>>>>> to optimize gpu wake up latency. >>>>>> >>>>>> Cc: Arnd Bergmann <arnd@xxxxxxxxxx> >>>>>> >>>>>> Signed-off-by: Akhil P Oommen <quic_akhilpo@xxxxxxxxxxx> >>>>>> --- >>>>>> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 + >>>>>> drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 34 ++++++++++++++++++++++------------ >>>>>> 2 files changed, 23 insertions(+), 12 deletions(-) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h >>>>>> index 94b6c5cab6f4..b4a79f88ccf4 100644 >>>>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h >>>>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h >>>>>> @@ -99,6 +99,7 @@ struct a6xx_gmu { >>>>>> struct completion pd_gate; >>>>>> >>>>>> struct qmp *qmp; >>>>>> + struct a6xx_hfi_msg_bw_table *bw_table; >>>>>> }; >>>>>> >>>>>> static inline u32 gmu_read(struct a6xx_gmu *gmu, u32 offset) >>>>>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c >>>>>> index cdb3f6e74d3e..55e51c81be1f 100644 >>>>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c >>>>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c >>>>>> @@ -630,32 +630,42 @@ static void a6xx_build_bw_table(struct a6xx_hfi_msg_bw_table *msg) >>>>>> >>>>>> static int a6xx_hfi_send_bw_table(struct a6xx_gmu *gmu) >>>>>> { >>>>>> - struct a6xx_hfi_msg_bw_table msg = { 0 }; >>>>>> + struct a6xx_hfi_msg_bw_table *msg; >>>>>> struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu); >>>>>> struct adreno_gpu *adreno_gpu = &a6xx_gpu->base; >>>>>> >>>>>> + if (gmu->bw_table) >>>>>> + goto send; >>>>>> + >>>>>> + msg = devm_kzalloc(gmu->dev, sizeof(*msg), GFP_KERNEL); >>>>> >>>>> Is it necessary after being sent? Isn't it better to just kzalloc() it >>>>> and then kfree() it at the end of the function? >>>> >>>> Keeping it around will help to cut down unnecessary work during >>>> subsequent gpu wake ups. >>> >>> Then, I'd say, it is better to make it a part of the a6xx_gpu struct. >> >> I think a6xx_gmu makes more logical sense here. >> >> FWIW, the driver allocates both _gmu and _gpu for all GPUs regardless > > Hmm, are we expected to handle / perform BW requests in case of GMU-less > devices? opp-table does that for us In case of no gmu ("gmu wrapper"), Linux is the only entity that controls things Konrad