From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E07EB304BDE; Tue, 12 May 2026 10:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778580135; cv=none; b=hhp+nt6W+ixxzfJiEP8sBy4qcCQeVcAMv62xE4nK/oG3cx+EMlEJcMm6orpQrygt16dxcQ0kVQQ6tb/ZUbkRFPa5efO1CBAwnOezxGHeLav/EnvZj9AtdZw0xsSZCatZ6DhOzuaOmRzKpYyAz0nJZTaDrDNC1orCvXMF60y0oII= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778580135; c=relaxed/simple; bh=OdJ8hnLE55pnh0p3P3j5HYTzhxj0FvpG6RmW2CniriM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=TayloxQLF3/Asg/pWRo9369KlyR8Lh1rmtI34b1wbYBlzqvzmeebJ8FGk9Ujy5KNNfPTE+ETZxybxwjI+jRJxCBYSUIfaIuDY3Ck0X0gtNYkYJ0H+Ic1aGtaoA3FqlZnk8I569GnbF5GvFDD5DM3BxubSwPU2h656Iv8yM+4Ygc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from edelgard.fodlan.icenowy.me (unknown [112.94.100.82]) by APP-03 (Coremail) with SMTP id rQCowAB3XOOS+gJqcF_HEA--.15121S2; Tue, 12 May 2026 18:01:55 +0800 (CST) Message-ID: <4bf6efbb222ebc4d770ad613d17c6185e7cb2fda.camel@iscas.ac.cn> Subject: Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller From: Icenowy Zheng To: Joey Lu , maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org Cc: ychuang3@nuvoton.com, schung@nuvoton.com, yclu4@nuvoton.com, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Tue, 12 May 2026 18:01:54 +0800 In-Reply-To: References: <20260511075142.54752-1-a0987203069@gmail.com> <20260511075142.54752-3-a0987203069@gmail.com> <93e69179dbc495188cfffd8015350b3a55ce7876.camel@iscas.ac.cn> <3b94806073de8bd1d79aa7ec956493f67679e46b.camel@iscas.ac.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-CM-TRANSID:rQCowAB3XOOS+gJqcF_HEA--.15121S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWw1fWry8CF4fWryxAF4xWFg_yoWrCF4xpF WkKFWI9Fs3JryS9rsFk3WDKFyjyws7Kw4fWrn5WrnYgrnFkrn7WF4xtr17WF4v9F1kCr1I qF48GrWxur98ArUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvvb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lFIxGxcIEc7CjxVA2Y2ka0xkIwI1l c7CjxVAaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr 1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE 14v26r4a6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7 IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E 87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73Uj IFyTuYvjxUqiFxDUUUU X-CM-SenderInfo: x2kh0wp0lqwv3d6l2u1dvotugofq/ =E5=9C=A8 2026-05-12=E4=BA=8C=E7=9A=84 17:06 +0800=EF=BC=8CJoey Lu=E5=86=99= =E9=81=93=EF=BC=9A =3D=3D=3D=3D=3D=3D=3D 8< =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c > > > > > b/drivers/gpu/drm/verisilicon/vs_bridge.c > > > > > index 7a93049368db..225af322de32 100644 > > > > > --- a/drivers/gpu/drm/verisilicon/vs_bridge.c > > > > > +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c > > > > > @@ -164,13 +164,16 @@ static void > > > > > vs_bridge_enable_common(struct > > > > > vs_crtc *crtc, > > > > > =C2=A0=C2=A0=C2=A0 VSDC_DISP_PANEL_CONFIG_CLK_EN); > > > > > =C2=A0=C2=A0=C2=A0 regmap_set_bits(dc->regs, > > > > > VSDC_DISP_PANEL_CONFIG(output), > > > > > =C2=A0=C2=A0=C2=A0 VSDC_DISP_PANEL_CONFIG_RUNNING); > > > > > - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START, > > > > > - =09 > > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC); > > > > > - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START, > > > > > - > > > > > VSDC_DISP_PANEL_START_RUNNING(output)); > > > > > =C2=A0=C2=A0=20 > > > > > - regmap_set_bits(dc->regs, > > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc- > > > > > > id), > > > > > - VSDC_DISP_PANEL_CONFIG_EX_COMMIT); > > > > > + if (dc->info->has_config_ex) { > > > > > + regmap_clear_bits(dc->regs, > > > > > VSDC_DISP_PANEL_START, > > > > > + =09 > > > > > VSDC_DISP_PANEL_START_MULTI_DISP_SYNC); > > > > > + regmap_set_bits(dc->regs, > > > > > VSDC_DISP_PANEL_START, > > > > > + VSDC_DISP_PANEL_START_RUNNIN > > > > > G(ou > > > > > tput > > > > > )); > > > > > + > > > > > + regmap_set_bits(dc->regs, > > > > > VSDC_DISP_PANEL_CONFIG_EX(crtc->id), > > > > > + VSDC_DISP_PANEL_CONFIG_EX_CO > > > > > MMIT > > > > > ); > > > > Should the commit operation happen on DC8000/DCUltraLite too? > > > > (By > > > > writing to DcregFrameBufferConfig0.VALID). > > > >=20 > > > > Many registers written has "Note: This field is double > > > > buffered" in > > > > the > > > > DCUltraLite documentation. > > > >=20 > > > > I suggest create a static function for commit -- write to the > > > > corresponding commit bit on DC8200, and write to > > > > DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite. > > > [a] There is no commit operation for DCUltra Lite. > > > I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3)) is a > > > hardware-managed double-buffer status bit: hardware writes > > > 1=3DPENDING > > > when a new register set is ready and clears to 0=3DWORKING after > > > the > > > VBLANK copy. Software must never write it, and there is no > > > polling > > > use > > It seems to be writable and controls whether register buffering is > > enabled, see [1]. > >=20 > > The description of this bit in MA35D1 TRM says "This ensures a > > frame > > will always start with a valid working set if this register is > > programmed last, which reduces the need for SW to wait for the > > start of > > a VBLANK signal in order to ensure all states are loaded before the > > next VBLANK", which indicates some kind of "committing write", > > although > > the code at [1] seems to indicate that double buffering is only > > enabled > > when bit is cleared. > >=20 > > Anyway this bit should be programmable, and "Software must never > > write > > it" contradicts with the MA35D1 TRM. > >=20 > > Thanks, > > Icenowy > >=20 > > [1] > > https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/driver= s/gpu/drm/eswin/es_dc_hw.c#L993 > Thank you for the correction. I'll add > `#define VSDC_FB_CONFIG_VALID BIT(3)` to vs_primary_plane_regs.h and > write it in `vs_primary_plane_commit()` for non-config_ex variants. > > > case in the driver that requires a named constant. For non- > > > config_ex > > > variants, `vs_primary_plane_commit()` performs no commit > > > operation =E2=80=94 > > > `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in > > > `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4)) is > > > set/cleared in the bridge enable/disable paths. Well according to the driver code for DC8000 from Eswin, and the bit named "VALID", maybe it should be cleared before programming the registers, and set after programming registers, to make the process of programming registers atomic from the perspective of the display controller. Anyway this should require testing on real hardware to verify. By the way, I see multiple peripheral drivers for MA35D1 get applied in the torvalds tree, but the device tree is still only a skeleton; when will the device tree be updated? Thanks, Icenowy > > =3D=3D=3D=3D=3D=3D=3D=3D=3D 8< =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20