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: <CAH2e8h6m6q+fq==cVGA-=iUJC7qxZvomhCqm904AtH9CceL6ow@mail.gmail.com>
Date: Fri, 1 Aug 2025 22:27:33 +0800
From: Pengyu Luo <mitltlatltl@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: 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 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.

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