[PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

[Limonciello, Mario]

[Public]



> -----Original Message-----
> From: Alex Deucher <alexdeucher at gmail.com>
> Sent: Tuesday, January 17, 2023 09:11
> To: Guilherme G. Piccoli <gpiccoli at igalia.com>
> Cc: Limonciello, Mario <Mario.Limonciello at amd.com>; Liu, Leo
> <Leo.Liu at amd.com>; amd-gfx at lists.freedesktop.org; Jiang, Sonny
> <Sonny.Jiang at amd.com>; kernel at gpiccoli.net; Pan, Xinhui
> <Xinhui.Pan at amd.com>; dri-devel at lists.freedesktop.org; Lazar, Lijo
> <Lijo.Lazar at amd.com>; kernel-dev at igalia.com; Deucher, Alexander
> <Alexander.Deucher at amd.com>; Zhu, James <James.Zhu at amd.com>;
> Koenig, Christian <Christian.Koenig at amd.com>; Pierre-Loup Griffais
> <pgriffais at valvesoftware.com>
> Subject: Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force
> (en/dis)abling indirect SRAM mode
> 
> On Tue, Jan 17, 2023 at 9:33 AM Guilherme G. Piccoli
> <gpiccoli at igalia.com> wrote:
> >
> > On 16/01/2023 23:33, Limonciello, Mario wrote:
> > > [...]
> > >
> > > For debugging these type of problems, I think an effective debugging
> > > tactic would have been to mask the IP block (amdgpu.ip_block_mask).
> >
> > Thank you, it worked indeed - nice suggestion!
> >
> > Though I see two problems with that: first, I'm not sure what's the
> > impact in the GPU functioning when I disable some IP block.
> >

It depends on the individual block what the impact is.  For example
if you don't have VCN, then you can't do any accelerated video playback.

> > Second, the parameter is a bit hard to figure - we need to clear a bit
> > for the IP block we want to disable, and the doc suggest to read on
> > dmesg to get this information (it seems it changes depending on the HW
> > model), but I couldn't parse the proper bit from dmesg. Needed to
> > instrument the kernel to find the proper bit heh
> >

Isn't it this stuff (taken from a CZN system):

[    7.797779] [drm] add ip block number 0 <soc15_common>
[    7.797781] [drm] add ip block number 1 <gmc_v9_0>
[    7.797782] [drm] add ip block number 2 <vega10_ih>
[    7.797783] [drm] add ip block number 3 <psp>
[    7.797783] [drm] add ip block number 4 <smu>
[    7.797784] [drm] add ip block number 5 <dm>
[    7.797785] [drm] add ip block number 6 <gfx_v9_0>
[    7.797786] [drm] add ip block number 7 <sdma_v4_0>
[    7.797787] [drm] add ip block number 8 <vcn_v2_0>
[    7.797788] [drm] add ip block number 9 <jpeg_v2_0>

So for that system it would be bit 8 to disable vcn.

In terms of how debugging would work:
I would expect when you get your failure it will have been the previous
block # that failed, and so you can reboot with that block masked and
see if you get further.

> > The second part is easy to improve (we can just show this bit in
> > dmesg!), I might do that instead of proposing this parameter, which
> > seems didn't raise much excitement after all heheh
> >
> > Finally, I'm still curious on why Deck was working fine with the
> > indirect SRAM mode disabled (by mistake) in many kernels - was it in
> > practice the same as disabling the VCN IP block?
> 
> IIRC, it depends on the fuse recipe for the particular ASIC.
> 
> Alex
> 
> 
> >
> > Thanks,
> >
> >
> > Guilherme
> >