| 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
| ||
|
Message-ID: <4e340eb246e4e725754ed2097260c1a1acd8fe71.camel@icenowy.me>
Date: Thu, 29 Jan 2026 00:03:01 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Thomas Zimmermann <tzimmermann@...e.de>, Andrzej Hajda
<andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>, Laurent Pinchart
<Laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>,
Jernej Skrabec <jernej.skrabec@...il.com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Rob
Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
Dooley <conor+dt@...nel.org>, Drew Fustini <fustini@...nel.org>, Guo Ren
<guoren@...nel.org>, Fu Wei <wefu@...hat.com>
Cc: Philipp Zabel <p.zabel@...gutronix.de>, Dmitry Baryshkov
<lumag@...nel.org>, Michal Wilczynski <m.wilczynski@...sung.com>, Luca
Ceresoli <luca.ceresoli@...tlin.com>, Han Gao <rabenda.cn@...il.com>, Yao
Zi <ziyao@...root.org>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-riscv@...ts.infradead.org, Han Gao <gaohan@...as.ac.cn>
Subject: Re: [PATCH v6 3/9] drm: verisilicon: add a driver for Verisilicon
display controllers
在 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@...nowy.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@...nowy.me>
> > > > Signed-off-by: Icenowy Zheng <zhengxingda@...as.ac.cn>
> > > > Tested-by: Han Gao <gaohan@...as.ac.cn>
> > > > Tested-by: Michal Wilczynski <m.wilczynski@...sung.com>
> > > Reviewed-by: Thomas Zimmermann <tzimmermann@...e.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?
Thanks,
Icenowy
>
> Best regards
> Thomas
>
> >
> > > Best regards
> > > Thomas
> > >
> > > > ---
> > > > Changes in v6:
> > > > - Sorted Kconfig dependency.
> > > > - Get rid of obsolete uppercase DRM_* printk marcos.
> > > > - Optimization to printk messages (unknown IRQ message is only
> > > > printed
> > > > once, device recognition message has "Found" added,
> > > > "Skipping
> > > > output"
> > > > message priority lowered to debug).
> > > > - Splitted most bridge functions for DPI/DP output.
> > > > - Get rid of custom CRTC atomic_flush, which doesn't do
> > > > anything
> > > > device-specific.
> > > > - Adapted macro HZ_PER_KHZ and VSDC_DISP_TIMING_VALUE_MAX.
> > > > - Switched to use drm_mode_size_dumb() to align dumb buffer
> > > > pitch.
> > > > - Reordered some function calls in vs_drm_initialize() (
> > > > aperture_remove_all_conflicting_devices() is now called
> > > > earlier
> > > > and
> > > > drm_mode_config_reset() is now called later).
> > > > - Splitted out vs_fb_get_dma_addr() and switched to use
> > > > drm_format_info_min_pitch() to calculate the src X offset
> > > > to the
> > > > framebuffer address.
> > > > - Splitted out atomic_{en,dis}able for primary plane.
> > > > - Removed an unused pm_runtime.h inclusion because the driver
> > > > now
> > > > does
> > > > not do runpm.
> > > >
> > > > Changes in v5:
> > > > - Switching to drm_atomic_get_new_bridge_state, which seems to
> > > > let
> > > > the
> > > > driver get rid of the hack of saving bus format itself.
> > > > - Add the internal bridge before attaching it.
> > > > - Adapted next_bridge struct field name suggested by Luca
> > > > Ceresoli.
> > > > - Refactored the probe code to not use port count, to allow
> > > > port@0
> > > > being
> > > > missing.
> > > >
> > > > Changes in v4:
> > > > - Switch to drm_* logger when we're handling with struct
> > > > drm_device.
> > > >
> > > > Changes in v3:
> > > > - Get rid of drm_atomic_get_existing_crtc_state() which is
> > > > marked
> > > > deprecated.
> > > >
> > > > Changes in v2:
> > > > - Changed some Control flows according to previous reviews.
> > > > - Added missing of_node_put when checking of endpoints for
> > > > output
> > > > type.
> > > > - Switched all userspace-visible modeset objects to be managed
> > > > by
> > > > drmm
> > > > instead of devm.
> > > > - Utilize devm_drm_bridge_alloc() in internal bridge.
> > > > - Prevented the usage of simple encoder helpers by passing a
> > > > NULL
> > > > funcs pointer.
> > > > - Let devm enable clocks when getting them.
> > > > - Removed explicit `.cache_type = REGCACHE_NONE` in regmap
> > > > config.
> > > > - Fixed a debug print using a variable before initialization.
> > > > - Fixed a wrong index when using bulk to handle resets.
> > > > - Added missing configuration for DPI format (currently fixed
> > > > RGB888).
> > > >
> > > > drivers/gpu/drm/Kconfig | 2 +
> > > > drivers/gpu/drm/Makefile | 1 +
> > > > drivers/gpu/drm/verisilicon/Kconfig | 15 +
> > > > drivers/gpu/drm/verisilicon/Makefile | 5 +
> > > > drivers/gpu/drm/verisilicon/vs_bridge.c | 371
> > > > ++++++++++++++++++
> > > > drivers/gpu/drm/verisilicon/vs_bridge.h | 39 ++
> > > > drivers/gpu/drm/verisilicon/vs_bridge_regs.h | 54 +++
> > > > drivers/gpu/drm/verisilicon/vs_crtc.c | 191
> > > > +++++++++
> > > > drivers/gpu/drm/verisilicon/vs_crtc.h | 31 ++
> > > > drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 60 +++
> > > > drivers/gpu/drm/verisilicon/vs_dc.c | 207
> > > > ++++++++++
> > > > drivers/gpu/drm/verisilicon/vs_dc.h | 38 ++
> > > > drivers/gpu/drm/verisilicon/vs_dc_top_regs.h | 27 ++
> > > > drivers/gpu/drm/verisilicon/vs_drm.c | 182
> > > > +++++++++
> > > > drivers/gpu/drm/verisilicon/vs_drm.h | 28 ++
> > > > drivers/gpu/drm/verisilicon/vs_hwdb.c | 150 +++++++
> > > > drivers/gpu/drm/verisilicon/vs_hwdb.h | 29 ++
> > > > drivers/gpu/drm/verisilicon/vs_plane.c | 124 ++++++
> > > > drivers/gpu/drm/verisilicon/vs_plane.h | 72 ++++
> > > > .../gpu/drm/verisilicon/vs_primary_plane.c | 173 ++++++++
> > > > .../drm/verisilicon/vs_primary_plane_regs.h | 53 +++
> > > > 21 files changed, 1852 insertions(+)
> > > > create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
> > > > create mode 100644 drivers/gpu/drm/verisilicon/Makefile
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_bridge.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_bridge.h
> > > > create mode 100644
> > > > drivers/gpu/drm/verisilicon/vs_bridge_regs.h
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
> > > > create mode 100644
> > > > drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
> > > > create mode 100644
> > > > drivers/gpu/drm/verisilicon/vs_dc_top_regs.h
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_drm.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_drm.h
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_hwdb.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_hwdb.h
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
> > > > create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
> > > > create mode 100644
> > > > drivers/gpu/drm/verisilicon/vs_primary_plane.c
> > > > create mode 100644
> > > > drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
>
Powered by blists - more mailing lists