> -----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.
