On 17/01/2023 13:24, Limonciello, Mario wrote: > [...] >>> 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. > Thanks Mario, much appreciated! You're totally right and I messed up not seeing these obvious messages... So, I'll just drop the parameter on V2. Cheers, Guilherme
