[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7d79542aedb6c074c4be21eaa15c71a53e87da4.camel@icenowy.me>
Date: Tue, 07 Oct 2025 00:33:06 +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-25星期四的 13:57 +0800,Icenowy Zheng写道:
> 在 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.ya
> > > > > > ml
> > > > > >
> > > > > > 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
> ```
>
Rob,
Is this an acceptable answer of not having a vendor-specific
compatible?
If it isn't, I will add vendor-specific compatible strings to the next
revision of the binding, and maybe also try to add them for vivante,gc.
Thanks,
Icenowy
> 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.
> >
>
Powered by blists - more mailing lists