devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Icenowy Zheng <uwu@icenowy.me>
To: Conor Dooley <conor@kernel.org>,
	Conor Dooley <conor.dooley@microchip.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Marc Zyngier <maz@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Jisheng Zhang <jszhang@kernel.org>,
	Samuel Holland <samuel@sholland.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/3] dt-bindings: timer: sifive,clint: add compatible for OpenC906
Date: Tue, 06 Dec 2022 11:46:11 +0800	[thread overview]
Message-ID: <86d822f73f6e61c9f286e800db50e9959aef05a0.camel@icenowy.me> (raw)
In-Reply-To: <B1B2FC9D-D971-435B-A9FD-B092DE726367@kernel.org>

在 2022-12-05星期一的 16:54 +0000,Conor Dooley写道:
> 
> 
> On 5 December 2022 15:59:44 GMT, Icenowy Zheng <uwu@icenowy.me>
> wrote:
> > 在 2022-12-05星期一的 15:05 +0000,Conor Dooley写道:
> > > On Mon, Dec 05, 2022 at 07:03:17PM +0800, Icenowy Zheng wrote:
> > > > 在 2022-12-05星期一的 10:36 +0000,Conor Dooley写道:
> > > 
> > > > > You lot all know the situation here a lot more than I do...
> > > > > I don't think "letting" people use the bare "thead,c900-foo"
> > > > > makes
> > > > > much
> > > > > sense as it gives us no chance to deal with quirks down the
> > > > > line.
> > > > 
> > > > Well, after rechecking the manual, I found it possible to
> > > > handle
> > > > quirks
> > > > -- T-Head has a custom "mcpuid" CSR (@ RISC-V CSR 0xFC0), which
> > > > can
> > > > be
> > > > used to retrieve some identification info of the core,
> > > > including
> > > > its
> > > > model ID, version, etc; and the T-Head PLIC/CLINT are part of
> > > > their
> > > > C906 SoC design that there's another "mapbaddr" CSR that could
> > > > be
> > > > used
> > > > to retrieve the base address of them.
> > > > 
> > > > So I think it okay to just use "thead,c900-clint" here, and
> > > > when
> > > > necessary, try to retrieve mcpuid for dealing with quirks.
> > > 
> > > I'm not super sure I follow. What's the relevance of "mapbaddr"
> > > here?
> > > We've got a reg property, so I don't think we need "mapbaddr"?
> > 
> > Yes, it's not relevant to us here, it's only to prove that
> > PLIC/CLINT
> > is part of C906 "Core Complex".
> > 
> > > 
> > > For "mcpuid", can you be sure that implementers will not omit
> > > setting
> > > that value to something unique? I'd be happier if we were overly
> > > clear
> > > now rather than have some headaches later. Have I missed
> > > something?
> > 
> > These values are set by T-Head instead of individual SoC
> > implementers
> > as a CPU CSR, and it's not for uniqueness, but it's for
> > identification
> > of the CPU core revision (thus the PLIC/CLINT that come with it).
> 
> I really am missing something here that must be obvious to you.
> Let me try and explain where my gap in understanding is.
> If someone takes the open cores & makes a minor tweak in the plic how
> does knowing mcpuid help us identify that that plic is marginally
> different?

No, but my point is that in this situation we shouldn't use C900
compatible at all because it's no longer the vanilla C900 cores.

My assumption is that the same IP cores are the same unless specially
customized.

> 
> I must have missed something that should be apparent and look like an
> eejit right now!
> 
> > 
> > > 
> > > > > I don't think that using "thead,openc906-clint", "thead,c900-
> > > > > clint"
> > > > > makes all that much sense either, in case someone does
> > > > > something
> > > > > wacky
> > > > > with the open-source version of the core.
> > > > > 
> > > > > That leaves us with either:
> > > > > "vendor,soc-clint", "thead,openc906-clint", "thead,c900-
> > > > > clint"
> > > > > or:
> > > > > "vendor,soc-clint", "thead,c900-clint"
> > > > > right?
> > > > > 
> > > > > The first one seems like possibly the better option as you'd
> > > > > kinda
> > > > > expect that, in a perfect word, all of the open-source IP
> > > > > implementations would share quirks etc?
> > > 
> > 


  reply	other threads:[~2022-12-06  3:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  4:17 [PATCH 0/3] Some DT binding quirks for T-Head C9xx Icenowy Zheng
2022-11-21  4:17 ` [PATCH 1/3] dt-bindings: timer: sifive,clint: add comaptibles for T-Head's C9xx Icenowy Zheng
2022-11-21 10:06   ` Krzysztof Kozlowski
2022-11-26 19:39   ` Samuel Holland
2022-11-27  7:25   ` Icenowy Zheng
2022-12-07 10:47   ` Icenowy Zheng
2022-12-07 11:33     ` Conor Dooley
2022-11-21  4:17 ` [PATCH 2/3] dt-bindings: timer: sifive,clint: add compatible for OpenC906 Icenowy Zheng
2022-11-21 10:06   ` Krzysztof Kozlowski
2022-11-22  7:18     ` Icenowy Zheng
2022-11-22  7:35       ` Krzysztof Kozlowski
2022-11-22  7:41         ` Icenowy Zheng
2022-11-22  8:47           ` Krzysztof Kozlowski
2022-11-30 18:13           ` Rob Herring
2022-12-01 19:18             ` Conor Dooley
2022-12-02  6:12               ` Icenowy Zheng
2022-12-05 10:36                 ` Conor Dooley
2022-12-05 11:03                   ` Icenowy Zheng
2022-12-05 15:05                     ` Conor Dooley
2022-12-05 15:59                       ` Icenowy Zheng
2022-12-05 16:54                         ` Conor Dooley
2022-12-06  3:46                           ` Icenowy Zheng [this message]
2022-12-06  6:33                             ` Conor Dooley
2022-11-21  4:17 ` [PATCH 3/3] dt-bindings: interrupt-controller: sifive,plic: add OpenC906 compatible Icenowy Zheng
2022-11-21 10:06   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86d822f73f6e61c9f286e800db50e9959aef05a0.camel@icenowy.me \
    --to=uwu@icenowy.me \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jszhang@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=samuel@sholland.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).