On Mon, Jun 8, 2020 at 3:25 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: > > On Wed, Mar 25, 2020 at 1:17 AM Kalyan Thota <kalyan_t@xxxxxxxxxxxxxx> wrote: > > > > This change adds support to configure dspp blocks in > > the dpu driver. > > > > Macro description of the changes coming in this patch. > > 1) Add dspp definitions in the hw catalog. > > 2) Add capability to reserve dspp blocks in the display data path. > > 3) Attach the reserved block to the encoder. > > > > Signed-off-by: Kalyan Thota <kalyan_t@xxxxxxxxxxxxxx> > > Hey all, > With this patch now merged upstream, I'm seeing a regression on > db845c that I bisected down to it. > > When I boot up I see: > [ 40.976737] [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu > error]failed to get dspp on lm 0 > [ 40.985600] [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu > error]failed to get dspp on lm 0 > [ 40.994587] [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu > error]failed to get dspp on lm 0 > [ 41.003492] [drm:_dpu_rm_check_lm_and_get_connected_blks] [dpu > error]failed to get dspp on lm 0 > [ 41.012283] [drm:_dpu_rm_make_reservation] [dpu error]unable to > find appropriate mixers > [ 41.020369] [drm:dpu_rm_reserve] [dpu error]failed to reserve hw > resources: -119 > > Over and over, and the display doesn't start up. > > I suspect we're supposed to catch the following check before the failure: > > + if (!reqs->topology.num_dspp) > + return true; > > I suspect the issue is in dpu_encoder_get_topology() we don't fully > initialize the topology structure on the stack before returning it. > > Does that sound plausible or is there likely some other cause? This guess is wrong. The topology.num_dspp is 2, but lm_cfg->dspp is coming back as zero. I'll continue digging to see if I can understand better whats going wrong. thanks -john
