drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-)
IGT reported test failures with Gamma correction block on SC7180.
Disable GC subblock on SC7180 until we trage the issue.
Cc: Federico Amedeo Izzo <federico@izzo.pro>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Most likely I will squash this into the GC patch
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
index c990ba3b5db02d65934179d5ad42bd740f6944b2..b6415adcea10126fb6bb29d60a9d4159052a61ba 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h
@@ -103,7 +103,7 @@ static const struct dpu_dspp_cfg sc7180_dspp[] = {
{
.name = "dspp_0", .id = DSPP_0,
.base = 0x54000, .len = 0x1800,
- .sblk = &sdm845_dspp_sblk,
+ .sblk = &sc7180_dspp_sblk,
},
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 23bb39b471b71e3f313321ad1c7a6bd4d2159019..bfd34368a03641651530d9c564a74d2e9398f656 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -389,6 +389,15 @@ static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
.len = 0x90, .version = 0x40000},
};
+/*
+ * Some of Gamma-related IGT tests fail on SC7180. Disable GC until we triage
+ * those failures.
+ */
+static const struct dpu_dspp_sub_blks sc7180_dspp_sblk = {
+ .pcc = {.name = "pcc", .base = 0x1700,
+ .len = 0x90, .version = 0x40000},
+};
+
static const struct dpu_dspp_sub_blks sm8750_dspp_sblk = {
.pcc = {.name = "pcc", .base = 0x1700,
.len = 0x90, .version = 0x60000},
---
base-commit: e2f085ab8636fae2ebe0adf42071e7558234cd7b
change-id: 20251115-dpu-fix-gc-931feac75705
Best regards,
--
With best wishes
DmitryOn 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 <federico@izzo.pro> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > --- > 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 What tests are exactly failing? I couldn't track it down on FDO GL Konrad
On Mon, 17 Nov 2025 at 13:25, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> 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 <federico@izzo.pro> > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> > > --- > > 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 -- With best wishes Dmitry
On 11/17/25 12:51 PM, Dmitry Baryshkov wrote:
> On Mon, 17 Nov 2025 at 13:25, Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> 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 <federico@izzo.pro>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> 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
igt.kms_color@gamma.log 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?
Also, would that mean we can only have gamma control on a single active
LM at a time?
Konrad
On Mon, 17 Nov 2025 at 14:10, Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 11/17/25 12:51 PM, Dmitry Baryshkov wrote:
> > On Mon, 17 Nov 2025 at 13:25, Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> 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 <federico@izzo.pro>
> >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >>> ---
> >>> 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
>
> igt.kms_color@gamma.log 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.
> 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
--
With best wishes
Dmitry
On 11/17/25 2:16 PM, Dmitry Baryshkov wrote:
> On Mon, 17 Nov 2025 at 14:10, Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 11/17/25 12:51 PM, Dmitry Baryshkov wrote:
>>> On Mon, 17 Nov 2025 at 13:25, Konrad Dybcio
>>> <konrad.dybcio@oss.qualcomm.com> 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 <federico@izzo.pro>
>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>> ---
>>>>> 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
>>
>> igt.kms_color@gamma.log 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
© 2016 - 2026 Red Hat, Inc.