RE: [PATCH v3 2/6] dt-bindings: riscv: Add StarFive JH8100 SoC

[JeeHeng Sia]

> -----Original Message-----
> From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
> Sent: Friday, December 15, 2023 1:21 AM
> To: Conor Dooley <conor@xxxxxxxxxx>
> Cc: JeeHeng Sia <jeeheng.sia@xxxxxxxxxxxxxxxx>; kernel@xxxxxxxx; robh+dt@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx;
> krzk@xxxxxxxxxx; conor+dt@xxxxxxxxxx; Paul Walmsley <paul.walmsley@xxxxxxxxxx>; aou@xxxxxxxxxxxxxxxxx;
> daniel.lezcano@xxxxxxxxxx; tglx@xxxxxxxxxxxxx; anup@xxxxxxxxxxxxxx; Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; jirislaby@xxxxxxxxxx;
> michal.simek@xxxxxxx; Michael Zhu <michael.zhu@xxxxxxxxxxxxxxxx>; drew@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> riscv@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Leyfoon Tan <leyfoon.tan@xxxxxxxxxxxxxxxx>; Conor Dooley
> <conor.dooley@xxxxxxxxxxxxx>
> 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@xxxxxxxxxx>
> >> > Sent: Wednesday, December 13, 2023 8:43 PM
> >> > To: JeeHeng Sia <jeeheng.sia@xxxxxxxxxxxxxxxx>
> >> > Cc: kernel@xxxxxxxx; robh+dt@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx; krzk@xxxxxxxxxx; conor+dt@xxxxxxxxxx;
> >> > paul.walmsley@xxxxxxxxxx; palmer@xxxxxxxxxxx; aou@xxxxxxxxxxxxxxxxx; daniel.lezcano@xxxxxxxxxx; tglx@xxxxxxxxxxxxx;
> >> > anup@xxxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; jirislaby@xxxxxxxxxx; michal.simek@xxxxxxx; Michael Zhu
> >> > <michael.zhu@xxxxxxxxxxxxxxxx>; drew@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-riscv@xxxxxxxxxxxxxxxxxxx; linux-
> >> > kernel@xxxxxxxxxxxxxxx; Leyfoon Tan <leyfoon.tan@xxxxxxxxxxxxxxxx>; Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> >> > 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@xxxxxxxxxxxxxxxx>
> >> > > Reviewed-by: Ley Foon Tan <leyfoon.tan@xxxxxxxxxxxxxxxx>
> >> > > Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> >> > > ---
> >> > >  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.