[Public] > -----Original Message----- > From: Alex Deucher <alexdeucher@xxxxxxxxx> > Sent: Tuesday, January 17, 2023 09:11 > To: Guilherme G. Piccoli <gpiccoli@xxxxxxxxxx> > Cc: Limonciello, Mario <Mario.Limonciello@xxxxxxx>; Liu, Leo > <Leo.Liu@xxxxxxx>; amd-gfx@xxxxxxxxxxxxxxxxxxxxx; Jiang, Sonny > <Sonny.Jiang@xxxxxxx>; kernel@xxxxxxxxxxxx; Pan, Xinhui > <Xinhui.Pan@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx; Lazar, Lijo > <Lijo.Lazar@xxxxxxx>; kernel-dev@xxxxxxxxxx; Deucher, Alexander > <Alexander.Deucher@xxxxxxx>; Zhu, James <James.Zhu@xxxxxxx>; > Koenig, Christian <Christian.Koenig@xxxxxxx>; Pierre-Loup Griffais > <pgriffais@xxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxx> 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 > >
