mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Jessica Zhang <jesszhan0024@gmail.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Federico Amedeo Izzo <federico@izzo.pro>
Subject: Re: [PATCH] drm/msm/dpu: disable gamma correction unit on SC7180
Date: Mon, 17 Nov 2025 13:09:59 +0100	[thread overview]
Message-ID: <8541a10d-99ca-43d2-bafa-8e33bba01382@oss.qualcomm.com> (raw)
In-Reply-To: <CAO9ioeUfZQVy7VFUp8FEVHN2_uL0ZB9jbkuexWY4D12YN_O3Jw@mail.gmail.com>

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

  reply	other threads:[~2025-11-17 12:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-15  3:08 Dmitry Baryshkov
2025-11-17 11:25 ` Konrad Dybcio
2025-11-17 11:51   ` Dmitry Baryshkov
2025-11-17 12:09     ` Konrad Dybcio [this message]
2025-11-17 13:16       ` Dmitry Baryshkov
2025-11-17 13:39         ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8541a10d-99ca-43d2-bafa-8e33bba01382@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=federico@izzo.pro \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lumag@kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®