On 3/20/2025 7:23 PM, Alex Deucher wrote:
> On Thu, Mar 20, 2025 at 9:44 AM Lazar, Lijo <lijo.la...@amd.com> wrote:
>>
>>
>>
>> On 3/20/2025 6:21 PM, Alex Deucher wrote:
>>> On Thu, Mar 20, 2025 at 7:14 AM Lazar, Lijo <lijo.la...@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 3/20/2025 12:38 AM, Alex Deucher wrote:
>>>>> Break when we get to the end of the supported pipes
>>>>> rather than continuing the loop.
>>>>>
>>>>> Reviewed-by: Shaoyun.liu <shaoyun....@amd.com>
>>>>> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
>>>>> ---
>>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
>>>>> index 3b83880f9e2cc..10f14bf925778 100644
>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c
>>>>> @@ -132,7 +132,7 @@ int amdgpu_mes_init(struct amdgpu_device *adev)
>>>>> for (i = 0; i < AMDGPU_MES_MAX_COMPUTE_PIPES; i++) {
>>>>
>>>> Unless I'm not seeing something, why not just keep it i <
>>>> adev->gfx.mec.num_pipe_per_mec?
>>>
>>> AMDGPU_MES_MAX_COMPUTE_PIPES Is the size of the array and I think it
>>> is aligned to the max supported by the firmware, so if we had
>>> num_pipe_per_mec larger than that for some reason this would prevent
>>> an overflow.
>>>
>>
>> I think it should be kept the other way and array size should be fixed,
>> otherwise it hides a real problem.
>
> How about a dev_warn when we break out of the loop? If we see that,
> we can fix the array size or figure out why it's too large.
>
Yes, that will do.
Thanks,
Lijo
> Alex
>
>>
>> Thanks,
>> Lijo
>>
>>> Alex
>>>
>>>>
>>>> Thanks,
>>>> Lijo
>>>>
>>>>> /* use only 1st MEC pipes */
>>>>> if (i >= adev->gfx.mec.num_pipe_per_mec)
>>>>> - continue;
>>>>> + break;
>>>>> adev->mes.compute_hqd_mask[i] = 0xc;
>>>>> }
>>>>>
>>>>
>>
