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.
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;
> >>> }
> >>>
> >>
>
