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 <[email protected]> > > > > > > > > > > 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 <[email protected]> > > > > > Signed-off-by: Icenowy Zheng <[email protected]> > > > > > Tested-by: Han Gao <[email protected]> > > > > > Tested-by: Michal Wilczynski <[email protected]> > > > > Reviewed-by: Thomas Zimmermann <[email protected]> > > > > > > > > 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
