linux-kernel - Re: [PATCH v2 2/8] dt-bindings: display: add verisilicon,dc

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] [day] [month] [year] [list]
Message-ID: <84566b33d0d08ad070c3aa8a01e07f3a0e3bff50.camel@icenowy.me>
Date: Thu, 25 Sep 2025 13:57:03 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Christian Gmeiner <christian.gmeiner@...il.com>
Cc: Rob Herring <robh@...nel.org>, Lucas Stach <l.stach@...gutronix.de>, 
 Russell King <linux+etnaviv@...linux.org.uk>, moderated for non-subscribers
 <etnaviv@...ts.freedesktop.org>,  Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, 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>, Philipp Zabel
 <p.zabel@...gutronix.de>, Heiko Stuebner <heiko@...ech.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>, Michal Wilczynski
 <m.wilczynski@...sung.com>, Han Gao <rabenda.cn@...il.com>, Yao Zi
 <ziyao@...root.org>, dri-devel@...ts.freedesktop.org, 
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
 linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 2/8] dt-bindings: display: add verisilicon,dc

在 2025-09-24星期三的 20:15 +0200，Christian Gmeiner写道：
> > > > > Verisilicon has a series of display controllers prefixed with
> > > > > DC
> > > > > and
> > > > > with self-identification facility like their GC series GPUs.
> > > > > 
> > > > > Add a device tree binding for it.
> > > > > 
> > > > > Depends on the specific DC model, it can have either one or
> > > > > two
> > > > > display
> > > > > outputs, and each display output could be set to DPI signal
> > > > > or
> > > > > "DP"
> > > > > signal (which seems to be some plain parallel bus to HDMI
> > > > > controllers).
> > > > > 
> > > > > Signed-off-by: Icenowy Zheng <uwu@...nowy.me>
> > > > > ---
> > > > > Changes in v2:
> > > > > - Fixed misspelt "versilicon" in title.
> > > > > - Moved minItems in clock properties to be earlier than
> > > > > items.
> > > > > - Re-aligned multi-line clocks and resets in example.
> > > > > 
> > > > >  .../bindings/display/verisilicon,dc.yaml      | 127
> > > > > ++++++++++++++++++
> > > > >  1 file changed, 127 insertions(+)
> > > > >  create mode 100644
> > > > > Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/verisilicon,dc.ya
> > > > > ml
> > > > > b/Documentation/devicetree/bindings/display/verisilicon,dc.ya
> > > > > ml
> > > > > new file mode 100644
> > > > > index 0000000000000..07fedc4c7cc13
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/display/verisilicon,dc.ya
> > > > > ml
> > > > > @@ -0,0 +1,127 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id:
> > > > > http://devicetree.org/schemas/display/verisilicon,dc.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Verisilicon DC-series display controllers
> > > > > +
> > > > > +maintainers:
> > > > > +  - Icenowy Zheng <uwu@...nowy.me>
> > > > > +
> > > > > +properties:
> > > > > +  $nodename:
> > > > > +    pattern: "^display@[0-9a-f]+$"
> > > > > +
> > > > > +  compatible:
> > > > > +    const: verisilicon,dc
> > > > 
> > > > This needs an SoC specific compatible. Generally licensed IP
> > > > compatibles
> > > > are useless because the specs aren't public and there's always
> > > > integration quirks.
> > > 
> > > This mimics the GPU IPs by the same vendor, see
> > > gpu/vivante,gc.yaml ,
> > > which contain the exact same set of identification registers
> > > (including
> > > a "customer id" one that can differienate the same configured IP
> > > on
> > > StarFive JH7110 and T-Head TH1520).
> > > 
> > > If we can get vivante,gc to work w/o SoC specific compatible,
> > > then we
> > > should be able to get verisilicon,dc to work too.
> > 
> > Well maybe I should add etnaviv people to the recipient list, to
> > allow
> > them to tell us the magic behind vivante,gc .
> > 
> 
> Vivante GPUs are special because they contain registers that allow
> them to
> be fully identified - see etnaviv_hw_identify(..).
> 
> We can read out the following information:
>  - model
>  - revision
>  - product_id
>  - customer_id
>  - eco_id

Well Verisilicon DCs (sometimes also called Vivante DCs because Vivante
is now part of Verisilicon) except DCNano have the same set of ID
registers (In fact the registers before 0x1500 seem to have mostly the
same meaning with GPUs, see [1], here the registers are even named
GC{,REG}_xxx), so it's why I assume "verisilicon,dc" will work here.

An example of identification registers readout on TH1510 is shown
below: (the register names are from etnaviv state_hi.xml)
```
root@...4a66 [ ~ ] # busybox devmem 0xffef600020 # MODEL              
0x00008200
root@...4a66 [ ~ ] # busybox devmem 0xffef600024 # REV
0x00005720
root@...4a66 [ ~ ] # busybox devmem 0xffef600028 # DATE
0x20210201
root@...4a66 [ ~ ] # busybox devmem 0xffef60002c # TIME
0x11133000
root@...4a66 [ ~ ] # busybox devmem 0xffef600030 # CUSTOMER_ID
0x0000030A
root@...4a66 [ ~ ] # busybox devmem 0xffef6000a8 # PRODUCT_ID
0x02082000
root@...4a66 [ ~ ] # busybox devmem 0xffef6000e8 # ECO_ID
0x00000000
```

But as Rob pointed out, maybe acquiring informations from the IDs
cannot solve all the problem of integration quirks? As these IDs are
already determined when Verisilicon generates the RTL for the customer,
it's possible for them to reuse the RTL twice, mess up something in one
silicon and have the issues fixed in another.

[1]
https://github.com/milkv-megrez/rockos-u-boot/blob/c9221cf2fa77d39c0b241ab4b030c708e7ebe279/drivers/video/eswin/eswin_dc_reg.h

> 
> This information, in combination with a hardware database (hwdb) in
> kernel/userspace, is enough to support these GPUs/NPUs across
> different SoC vendors.
>