linux-kernel - Re: [PATCH 3/4] arm64: dts: qcom: sc8280xp: Add initial support for Ntmer TW220

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <t7fbgze3hnwbget5nkf3i2rd22pk5vufyimiiec5i7rblzb7x4@rtiuwnyfbmtb>
Date: Fri, 1 Aug 2025 20:27:24 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Pengyu Luo <mitltlatltl@...il.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, aliceryhl@...gle.com,
        andersson@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
        ebiggers@...gle.com, ilpo.jarvinen@...ux.intel.com,
        joel.granados@...nel.org, konradybcio@...nel.org, krzk+dt@...nel.org,
        len.brown@...el.com, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, lossin@...nel.org, mingo@...nel.org,
        ojeda@...nel.org, robh@...nel.org, sfr@...b.auug.org.au,
        vanyang@...il.nju.edu.cn, viro@...iv.linux.org.uk
Subject: Re: [PATCH 3/4] arm64: dts: qcom: sc8280xp: Add initial support for
 Ntmer TW220

On Fri, Aug 01, 2025 at 10:27:33PM +0800, Pengyu Luo wrote:
> On Fri, Aug 1, 2025 at 8:29 PM Konrad Dybcio
> <konrad.dybcio@....qualcomm.com> wrote:
> >
> > On 7/31/25 5:05 AM, Pengyu Luo wrote:
> > > Linux:
> > >> ae94000 20050001 000001f3 0000000b dddd1011
> > >> ae94010 00009130 31211101 3e2e1e0e 00001900
> > >> ae94020 00000000 05190019 064c000c 065f0528
> > >> ae94030 00060000 00000000 00040000 14000000
> > >> ae94040 06100006 00003c2c 00001000 00000008
> > > Windows:
> > >> ae94000 20050001 000001f7 00000008 00001010
> > >> ae94010 00009130 31211101 3e2e1e0e 00001900
> > >> ae94020 00000000 05320032 064c000c 065f0551
> > >> ae94030 000c0000 00000000 00040000 14000000
> > >> ae94040 00100008 00013c2c 9bb9b000 00000004
> >
> > 0xae94008 differs, bits 0 and 1 say that the cmd mode engine
> > is busy doing something (did you set MIPI_DSI_MODE_VIDEO?)
> >
> 
> Yes. I can confirm MIPI_DSI_MODE_VIDEO is set.
> 
> Speaking of cmd mode, I still have no idea why DSI_CTRL_CMD_MODE_EN
> (BIT(2) of 0xae94004) is enabled on Windows.
> 
> > 0xae94024 says:
> > Linux:
> > ACTIVE_H_END=1305
> > ACTIVE_H_START=25
> > Windows:
> > ACTIVE_H_END=1330
> > ACTIVE_H_START=50
> >
> > 0xae9402c:
> > Linux:
> > VTOTAL=1631
> > HTOTAL=1320
> > Windows:
> > VTOTAL=1631
> > HTOTAL=1361
> >
> > 0xae94030:
> > Linux:
> > HS_END=6
> > Windows:
> > HS_END=12
> >
> 
> I believe we can ignore them now, I found the final dump and verified
> it’s correct. Previously, I mistakenly halved the porch timings:
> 
> Incorrect:
> .hsync_total = (1280 + (32 + 12 + 38) / 2) * 2.

If you halved the porches... Is this panel using a single DSI host or
two DSI hosts? In the latter case you need to assign parents for DSI
clocks (see how it's done on the sdm845-db845c)

> 
> Correct:
> .hsync_total = (1280 + 32 + 12 + 38) * 2.
> 
> Here is the final dump on Linux
> # ae94000 20050001 000001f3 0000000b dddd1010
> # ae94010 00009130 31211101 3e2e1e0e 00001900
> # ae94020 00000000 05320032 064c000c 065f0551
> # ae94030 000c0000 00000000 00040000 14000000
> # ae94040 06100006 00003c2c 00001000 00000008
> 
> > 0xae94040:
> > Linux:
> > RGB565 (16 bpp)
> > bits 25/26 are "set RGB888 for DSI1 stream"
> > Windows:
> > RGB888 (24 bpp)
> >
> > (suggesting your panel driver is wrong)
> >
> > 0xae94044:
> > you may want to move the
> >
> > /* Always insert DCS command */
> > data |= DSI_CMD_CFG1_INSERT_DCS_COMMAND;
> > dsi_write(msm_host, REG_DSI_CMD_CFG1, data);
> >
> > in dsi_host.c out of the if (!video), not sure if it's correct
> > but that's what Windows seems to be setting
> >
> > The other differences are due to the current DCS command(s) being
> > processed
> >
> 
> It seems a normal behavior for video mode, for sm8650 in video mode,
> I’ve also seen:
> 
> # ae94040 06100006 00003c2c 00001000 00000004
> 
> These two registers are REG_DSI_CMD_CFG{0,1}, video mode uses
> REG_DSI_VID_CFG{0,1} whose values seem consistent between Linux and
> Windows.
> 
> >
> > Hope this helps
> >
> 
> Thanks a lot for your detailed analysis!
> 
> Best wishes,
> Pengyu

-- 
With best wishes
Dmitry