On 11/17/25 2:16 PM, Dmitry Baryshkov wrote: > On Mon, 17 Nov 2025 at 14:10, Konrad Dybcio > <[email protected]> wrote: >> >> On 11/17/25 12:51 PM, Dmitry Baryshkov wrote: >>> On Mon, 17 Nov 2025 at 13:25, Konrad Dybcio >>> <[email protected]> wrote: >>>> >>>> On 11/15/25 4:08 AM, Dmitry Baryshkov wrote: >>>>> IGT reported test failures with Gamma correction block on SC7180. >>>>> Disable GC subblock on SC7180 until we trage the issue. >>>>> >>>>> Cc: Federico Amedeo Izzo <[email protected]> >>>>> Signed-off-by: Dmitry Baryshkov <[email protected]> >>>>> --- >>>>> Most likely I will squash this into the GC patch >>>>> --- >>>> >>>> Peeking at downstream, 7180 and 845 should have the exact same GC >>>> (v1.8).. it seems like there's an attempt to program it through >>>> REGDMA instead of regular reg access. Not sure if it's actually >>>> necessary or just an optimization >>> >>> I think it's mostly an optimization. >>> >>>> What tests are exactly failing? I couldn't track it down on FDO GL >>> >>> See [1] and other failed SC7180 jobs from the same pipeline. I haven't >>> triaged it yet, but I assume this might be related to platform >>> resources (it has only 2 LM blocks and only 1 DSPP). >>> Another possibility is that maybe we need higher CFG bus bandwidth >>> when writing LUT registers. >>> >>> [1] https://gitlab.freedesktop.org/drm/msm/-/jobs/87878393 >> >> [email protected] fails, we get an ENAVAIL (-119) (which doesn't >> seem like a good return value for this error but anyway..), dmesg says >> >> 05:42:13.199: [ 75.472174] [drm:_dpu_rm_check_lm_and_get_connected_blks] >> [dpu error]failed to get dspp on lm 0 >> 05:42:13.199: [ 75.481487] [drm:_dpu_rm_make_reservation] [dpu >> error]unable to find appropriate mixers >> 05:42:13.199: [ 75.490235] [drm:dpu_rm_reserve] [dpu error]failed to >> reserve hw resources: -119 >> >> which comes from: >> >> idx = lm_cfg->dspp - DSPP_0; >> if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) { >> // misleading error message, it's not LM%d, but DSPP%d >> DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp); >> return false; >> } >> >> which comes from: >> >> static const struct dpu_lm_cfg sc7180_lm[] = { >> { >> .name = "lm_0", .id = LM_0, >> .base = 0x44000, .len = 0x320, >> .features = MIXER_MSM8998_MASK, >> .sblk = &sc7180_lm_sblk, >> .lm_pair = LM_1, >> .pingpong = PINGPONG_0, >> .dspp = DSPP_0, >> }, { >> .name = "lm_1", .id = LM_1, >> .base = 0x45000, .len = 0x320, >> .features = MIXER_MSM8998_MASK, >> .sblk = &sc7180_lm_sblk, >> .lm_pair = LM_0, >> .pingpong = PINGPONG_1, >> // no dspp here, errors out >> }, >> }; >> >> would simply binding .dspp = DSPP_0 to the other one just work here? > > Only LM_0 can use DSPP_0, that part is not flexible.
OK that makes sense > >> Also, would that mean we can only have gamma control on a single active >> LM at a time? > > We can only control gamma on LM_0 on this platform. > > BTW, the other log is more interesting: > > [3] https://gitlab.freedesktop.org/drm/msm/-/jobs/87895515/viewer I wonder if we need to take a closer look at this hunk: /* Disable 8-bit rounding mode */ gc_lut->flags = 0; also, IGT tests XRGB8888 - any chance the X is getting mistakenly (un)modified? Konrad
