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

  Add device tree bindings for the StarFive JH8100 RISC-V SoC.

Signed-off-by: Sia Jee Heng <jeeheng.sia@starfivetech.com>
Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 Documentation/devicetree/bindings/riscv/starfive.yaml | 4 ++++
 1 file changed, 4 insertions(+)
  

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@starfivetech.com>
> Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.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.

Thanks,
Conor.

> +          - const: starfive,jh8100
>  additionalProperties: true
>  
>  ...
> -- 
> 2.34.1
> 
>
  

> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, December 13, 2023 8:43 PM
> To: JeeHeng Sia <jeeheng.sia@starfivetech.com>
> Cc: kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> krzk@kernel.org; conor+dt@kernel.org; paul.walmsley@sifive.com;
> palmer@dabbelt.com; aou@eecs.berkeley.edu; daniel.lezcano@linaro.org;
> tglx@linutronix.de; anup@brainfault.org; gregkh@linuxfoundation.org;
> jirislaby@kernel.org; michal.simek@amd.com; Michael Zhu
> <michael.zhu@starfivetech.com>; drew@beagleboard.org;
> devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; linux-
> kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor
> Dooley <conor.dooley@microchip.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@starfivetech.com>
> > Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> > Acked-by: Conor Dooley <conor.dooley@microchip.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.
> 
> Thanks,
> Conor.

We have been testing on the FPGA/emulator for pre-silicon validation. It will have real silicon SoC next year.

Regards
Ley Foon
  

> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, December 13, 2023 8:43 PM
> To: JeeHeng Sia <jeeheng.sia@starfivetech.com>
> Cc: kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; krzk@kernel.org; conor+dt@kernel.org;
> paul.walmsley@sifive.com; palmer@dabbelt.com; aou@eecs.berkeley.edu; daniel.lezcano@linaro.org; tglx@linutronix.de;
> anup@brainfault.org; gregkh@linuxfoundation.org; jirislaby@kernel.org; michal.simek@amd.com; Michael Zhu
> <michael.zhu@starfivetech.com>; drew@beagleboard.org; devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; linux-
> kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor Dooley <conor.dooley@microchip.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@starfivetech.com>
> > Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> > Acked-by: Conor Dooley <conor.dooley@microchip.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. I did mention that in the cover letter as well.
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? Hope there is an updated Linux
upstream guideline that benefit other vendors.
> 
> Thanks,
> Conor.
> 
> > +          - const: starfive,jh8100
> >  additionalProperties: true
> >
> >  ...
> > --
> > 2.34.1
> >
> >
  

On Thu, Dec 14, 2023 at 12:36:57AM +0000, JeeHeng Sia wrote:
> 
> 
> > -----Original Message-----
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Wednesday, December 13, 2023 8:43 PM
> > To: JeeHeng Sia <jeeheng.sia@starfivetech.com>
> > Cc: kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; krzk@kernel.org; conor+dt@kernel.org;
> > paul.walmsley@sifive.com; palmer@dabbelt.com; aou@eecs.berkeley.edu; daniel.lezcano@linaro.org; tglx@linutronix.de;
> > anup@brainfault.org; gregkh@linuxfoundation.org; jirislaby@kernel.org; michal.simek@amd.com; Michael Zhu
> > <michael.zhu@starfivetech.com>; drew@beagleboard.org; devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; linux-
> > kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor Dooley <conor.dooley@microchip.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@starfivetech.com>
> > > Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> > > Acked-by: Conor Dooley <conor.dooley@microchip.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.

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

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

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

Cheers,
Conor.
  

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@kernel.org>
>> > Sent: Wednesday, December 13, 2023 8:43 PM
>> > To: JeeHeng Sia <jeeheng.sia@starfivetech.com>
>> > Cc: kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; krzk@kernel.org; conor+dt@kernel.org;
>> > paul.walmsley@sifive.com; palmer@dabbelt.com; aou@eecs.berkeley.edu; daniel.lezcano@linaro.org; tglx@linutronix.de;
>> > anup@brainfault.org; gregkh@linuxfoundation.org; jirislaby@kernel.org; michal.simek@amd.com; Michael Zhu
>> > <michael.zhu@starfivetech.com>; drew@beagleboard.org; devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; linux-
>> > kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor Dooley <conor.dooley@microchip.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@starfivetech.com>
>> > > Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
>> > > Acked-by: Conor Dooley <conor.dooley@microchip.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.

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

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.
  

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Friday, December 15, 2023 1:21 AM
> To: Conor Dooley <conor@kernel.org>
> Cc: JeeHeng Sia <jeeheng.sia@starfivetech.com>; kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org;
> krzk@kernel.org; conor+dt@kernel.org; Paul Walmsley <paul.walmsley@sifive.com>; aou@eecs.berkeley.edu;
> daniel.lezcano@linaro.org; tglx@linutronix.de; anup@brainfault.org; Greg KH <gregkh@linuxfoundation.org>; jirislaby@kernel.org;
> michal.simek@amd.com; Michael Zhu <michael.zhu@starfivetech.com>; drew@beagleboard.org; devicetree@vger.kernel.org; linux-
> riscv@lists.infradead.org; linux-kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor Dooley
> <conor.dooley@microchip.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@kernel.org>
> >> > Sent: Wednesday, December 13, 2023 8:43 PM
> >> > To: JeeHeng Sia <jeeheng.sia@starfivetech.com>
> >> > Cc: kernel@esmil.dk; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; krzk@kernel.org; conor+dt@kernel.org;
> >> > paul.walmsley@sifive.com; palmer@dabbelt.com; aou@eecs.berkeley.edu; daniel.lezcano@linaro.org; tglx@linutronix.de;
> >> > anup@brainfault.org; gregkh@linuxfoundation.org; jirislaby@kernel.org; michal.simek@amd.com; Michael Zhu
> >> > <michael.zhu@starfivetech.com>; drew@beagleboard.org; devicetree@vger.kernel.org; linux-riscv@lists.infradead.org; linux-
> >> > kernel@vger.kernel.org; Leyfoon Tan <leyfoon.tan@starfivetech.com>; Conor Dooley <conor.dooley@microchip.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@starfivetech.com>
> >> > > Reviewed-by: Ley Foon Tan <leyfoon.tan@starfivetech.com>
> >> > > Acked-by: Conor Dooley <conor.dooley@microchip.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.
  

On Fri, Dec 15, 2023 at 01:49:02AM +0000, JeeHeng Sia wrote:
> 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 sure you can send them as RFC, yes.