[PATCH v6 3/9] drm: verisilicon: add a driver for Verisilicon display controllers

[Drew Fustini]

On Thu, Jan 29, 2026 at 12:03:01AM +0800, Icenowy Zheng wrote:
> 在 2026-01-28星期三的 09:54 +0100，Thomas Zimmermann写道：
> > Hi
> > 
> > Am 28.01.26 um 09:39 schrieb Icenowy Zheng:
> > > 在 2026-01-28星期三的 08:58 +0100，Thomas Zimmermann写道：
> > > > Hi
> > > > 
> > > > Am 23.01.26 um 10:28 schrieb Icenowy Zheng:
> > > > > From: Icenowy Zheng <uwu at icenowy.me>
> > > > > 
> > > > > This is a from-scratch driver targeting Verisilicon DC-series
> > > > > display
> > > > > controllers, which feature self-identification functionality
> > > > > like
> > > > > their
> > > > > GC-series GPUs.
> > > > > 
> > > > > Only DC8200 is being supported now, and only the main
> > > > > framebuffer
> > > > > is set
> > > > > up (as the DRM primary plane). Support for more DC models and
> > > > > more
> > > > > features is my further targets.
> > > > > 
> > > > > As the display controller is delivered to SoC vendors as a
> > > > > whole
> > > > > part,
> > > > > this driver does not use component framework and extra bridges
> > > > > inside a
> > > > > SoC is expected to be implemented as dedicated bridges (this
> > > > > driver
> > > > > properly supports bridge chaining).
> > > > > 
> > > > > Signed-off-by: Icenowy Zheng <uwu at icenowy.me>
> > > > > Signed-off-by: Icenowy Zheng <zhengxingda at iscas.ac.cn>
> > > > > Tested-by: Han Gao <gaohan at iscas.ac.cn>
> > > > > Tested-by: Michal Wilczynski <m.wilczynski at samsung.com>
> > > > Reviewed-by: Thomas Zimmermann <tzimmermann at suse.de>
> > > > 
> > > > I only briefly looked over this revision, as v5 already seemed
> > > > quite
> > > > good. If you want to do a follow-up patch, see my other reply to
> > > > v5
> > > > on
> > > > storing hardware formats in the plane state.
> > > Well the kernel test robot found a small Kconfig problem in this
> > > revision -- DRM_DISPLAY_HELPER should be selected.
> > > 
> > > Maybe I'm going to send a v7 to address this.
> > > 
> > > Should I also make derived plane state a change in v7, or leave it
> > > as a
> > > follow-up?
> > 
> > That would require another round of review, I guess. Better leave it
> > for 
> > a separate series.
> > 
> > > 
> > > By the way, I think PATCH 1-5 should go through drm-misc tree, am I
> > > right? Who's going to pick it if going through drm-misc?
> > 
> > I can do that. In v7, you can merge patch 8 (MAINTAINERS) into patch
> > 3, 
> > so that it goes in as well.
> 
> Well then who should pick patch 9, the mailmap change?
> 
> I remember there is some tree for this kind of "trivial changes", but I
> forgot any detail about this.
> 
> > 
> > Patches 6 and 7 are small, so I can also take them into drm-misc if
> > they 
> > riscv maintainers are OK with that.
> 
> Well, I think there might be other TH1520 DT bits merged by Drew
> Fustini in this cycle?
> 
> Drew, can you read this? (I heard from Han Gao that his mail failed to
> get delivered to Drew). If you can read this, could you confirm that
> whether you want to merge DT patches?

Sorry for not giving a tag for the dts patches earlier. I'll do that
now. W=1 dtbs_check looks clean.

The dts patches should probably go through the thead-dt-for-next tree.
There were no other dts patches for the merge window so I had not
planned to send a thead-dt-for-next pull request for 6.20. Normally I
try to send the PR to Arnd by rc5.

I'm excited about this series so maybe there is still a possibility. If
the drivers changes are going into next now, then I could apply the dts
changes to thead-dt-for-next and ask the SoC maintainer team if it is
possible to accept a late dts PR. There is still the possibility of a
couple next releases before rc8 this weekend. The extra week for 6.19
might make this feasible.

Thanks,
Drew