Message-ID: <ab8bb47cbcca40649ff1e115ed34d3c1@EXMBX066.cuchost.com>
Date: Fri, 15 Dec 2023 01:49:02 +0000
From: JeeHeng Sia <jeeheng.sia@...rfivetech.com>
To: Palmer Dabbelt <palmer@...belt.com>, Conor Dooley <conor@...nel.org>
CC: "kernel@...il.dk" <kernel@...il.dk>, "robh+dt@...nel.org"
	<robh+dt@...nel.org>, "krzysztof.kozlowski+dt@...aro.org"
	<krzysztof.kozlowski+dt@...aro.org>, "krzk@...nel.org" <krzk@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>, Paul Walmsley
	<paul.walmsley@...ive.com>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
	"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "anup@...infault.org" <anup@...infault.org>, Greg KH
	<gregkh@...uxfoundation.org>, "jirislaby@...nel.org" <jirislaby@...nel.org>,
	"michal.simek@....com" <michal.simek@....com>, Michael Zhu
	<michael.zhu@...rfivetech.com>, "drew@...gleboard.org"
	<drew@...gleboard.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Leyfoon Tan <leyfoon.tan@...rfivetech.com>,
	Conor Dooley <conor.dooley@...rochip.com>
Subject: RE: [PATCH v3 2/6] dt-bindings: riscv: Add StarFive JH8100 SoC



> -----Original Message-----
> From: Palmer Dabbelt <palmer@...belt.com>
> Sent: Friday, December 15, 2023 1:21 AM
> To: Conor Dooley <conor@...nel.org>
> Cc: JeeHeng Sia <jeeheng.sia@...rfivetech.com>; kernel@...il.dk; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org;
> krzk@...nel.org; conor+dt@...nel.org; Paul Walmsley <paul.walmsley@...ive.com>; aou@...s.berkeley.edu;
> daniel.lezcano@...aro.org; tglx@...utronix.de; anup@...infault.org; Greg KH <gregkh@...uxfoundation.org>; jirislaby@...nel.org;
> michal.simek@....com; Michael Zhu <michael.zhu@...rfivetech.com>; drew@...gleboard.org; devicetree@...r.kernel.org; linux-
> riscv@...ts.infradead.org; linux-kernel@...r.kernel.org; Leyfoon Tan <leyfoon.tan@...rfivetech.com>; Conor Dooley
> <conor.dooley@...rochip.com>
> Subject: Re: [PATCH v3 2/6] dt-bindings: riscv: Add StarFive JH8100 SoC
> 
> On Thu, 14 Dec 2023 08:22:29 PST (-0800), Conor Dooley wrote:
> > On Thu, Dec 14, 2023 at 12:36:57AM +0000, JeeHeng Sia wrote:
> >>
> >>
> >> > -----Original Message-----
> >> > From: Conor Dooley <conor@...nel.org>
> >> > Sent: Wednesday, December 13, 2023 8:43 PM
> >> > To: JeeHeng Sia <jeeheng.sia@...rfivetech.com>
> >> > Cc: kernel@...il.dk; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org; krzk@...nel.org; conor+dt@...nel.org;
> >> > paul.walmsley@...ive.com; palmer@...belt.com; aou@...s.berkeley.edu; daniel.lezcano@...aro.org; tglx@...utronix.de;
> >> > anup@...infault.org; gregkh@...uxfoundation.org; jirislaby@...nel.org; michal.simek@....com; Michael Zhu
> >> > <michael.zhu@...rfivetech.com>; drew@...gleboard.org; devicetree@...r.kernel.org; linux-riscv@...ts.infradead.org; linux-
> >> > kernel@...r.kernel.org; Leyfoon Tan <leyfoon.tan@...rfivetech.com>; Conor Dooley <conor.dooley@...rochip.com>
> >> > Subject: Re: [PATCH v3 2/6] dt-bindings: riscv: Add StarFive JH8100 SoC
> >> >
> >> > On Fri, Dec 01, 2023 at 08:14:06PM +0800, Sia Jee Heng wrote:
> >> > > Add device tree bindings for the StarFive JH8100 RISC-V SoC.
> >> > >
> >> > > Signed-off-by: Sia Jee Heng <jeeheng.sia@...rfivetech.com>
> >> > > Reviewed-by: Ley Foon Tan <leyfoon.tan@...rfivetech.com>
> >> > > Acked-by: Conor Dooley <conor.dooley@...rochip.com>
> >> > > ---
> >> > >  Documentation/devicetree/bindings/riscv/starfive.yaml | 4 ++++
> >> > >  1 file changed, 4 insertions(+)
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/riscv/starfive.yaml b/Documentation/devicetree/bindings/riscv/starfive.yaml
> >> > > index cc4d92f0a1bf..12d7844232b8 100644
> >> > > --- a/Documentation/devicetree/bindings/riscv/starfive.yaml
> >> > > +++ b/Documentation/devicetree/bindings/riscv/starfive.yaml
> >> > > @@ -30,6 +30,10 @@ properties:
> >> > >                - starfive,visionfive-2-v1.3b
> >> > >            - const: starfive,jh7110
> >> > >
> >> > > +      - items:
> >> > > +          - enum:
> >> > > +              - starfive,jh8100-evb
> >> >
> >> > Hmm, reading some of the other threads it appears that the evaluation
> >> > platform that you guys have is actually just an FPGA? Could you please
> >> > provide more information as to what this "evb" actually is?
> >> >
> >> > If it is just an FPGA-based evaluation platform I don't think that we
> >> > want to merge patches for the platform. I'm fine with patches adding
> >> > peripheral support, but the soc/board dts files and things like pinctrl
> >> > or clock drivers I am not keen on.
> >> > Perhaps Emil also has an opinion on this.
> >> Eco the same reply here. I am not sure what you mean. We verified on FPGA & Emulator,
> >> and the logic is pretty much close to the real silicon.
> >
> > "Pretty much close" That doesn't give me confidence. The compatible
> > should uniquely identify an SoC, but if it is used for both the actual
> > SoC and for something "pretty much close" to the actual SoC then that
> > does not hold.
> 
> Ya, trying to have some pre-silicon FPGA-based platform alias with the
> real chip is a repice for disaster.
> 
> >> I did mention that in the cover letter as well.
> >
> > Ah apologies for missing that. I try to read cover letters but the
> > volume of mail gets to me at times.
> >
> >> I am new to Linux, so I am wondering if there is a Linux upstream guideline mentioning
> >> that pre-silicon software is not allowed to upstream?
> >
> > I wouldn't say that this is the case, but things like clock and pinctrl
> > drivers are the sort of things that are likely to vary in your "pretty
> > much close" as that is the kind of thing that change for your final
> > integration, versus a more "standalone" peripheral.
> 
> Yep, and since integration issues in the ASIC blocks can end up
> manifesting as SW-visible behavior in nearby blocks it's hard to just
> pull out the peripherals -- we sort of try by getting the DT topology to
> match the SOC, but there's always some mismatches.
Thank you everyone. I think I get your point. Is it possible to send "RFC"
patches for things like DT, clk&reset, and pinctrl? Please note that
these have been tested on FPGA/Emulator.
> 
> > For dts stuff, in RISC-V at least, we've been operating so far on the
> > basis that systems implemented entirely on an FPGA are not suitable for
> > inclusion in mainline. I would say that this can probably be relaxed to
> > allow systems where there are publicly available, versioned, designs or
> > bitstreams that are widely used that these devicetrees correspond to.
> > This would suit something like if AMD published a bitstream using one
> > of their new MicroblazeV cpu cores as a sort of "reference design".
> 
> FPGAs are definately in a grey area, but that's been my mindset as well.
> For me it's less about FPGA vs ASIC (or any other manufacturing
> technology in between) and more about whether something is being used
> publicly.  Specifically: is the FPGA used for internal pre-silicon work
> or is it some publicly availiable system?
It is internal.
> 
> The versioning stuff is also important, but we need that for ASICs as
> well since they can be re-spun.
> 
> >> Hope there is an updated Linux
> >> upstream guideline that benefit other vendors.
> >
> > I have no idea if there is one or not. I think it generally varies on
> > individual maintainers etc, and for something like a dts it comes down
> > to the platform maintainer (Emil) I suppose. Sending stuff out before
> > your SoC has been produced is really great though, so it is a fine line
> > to avoid discouraging something we really like to see.
> 
> IIRC we've got some stuff written for arch/riscv somewhere in
> Documentation, but the hardest part here is that each subsystem is going
> to have different policies so it's kind of hard to try and come up with
> a general rule.
> 
> > Cheers,
> > Conor.

Powered by blists - more mailing lists