Message-ID: <20231107-darkening-daylong-deef34169798@spud>
Date:   Tue, 7 Nov 2023 21:36:55 +0000
From:   Conor Dooley <conor@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Michal Simek <michal.simek@....com>, linux-kernel@...r.kernel.org,
        monstr@...str.eu, michal.simek@...inx.com, git@...inx.com,
        Conor Dooley <conor+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        palmer@...belt.com
Subject: Re: [PATCH] dt-bindings: soc: Add new board description for
 MicroBlaze V

+CC Palmer

On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
> On 07/11/2023 13:09, Michal Simek wrote:
> > On 11/7/23 12:27, Krzysztof Kozlowski wrote:
> >> On 07/11/2023 12:09, Michal Simek wrote:
> >>> On 11/6/23 18:07, Conor Dooley wrote:
> >>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:

> >>>>> +description: |
> >>>>> +  AMD boards with MicroBlaze V SOC
> >>>>> +
> >>>>> +properties:
> >>>>> +  $nodename:
> >>>>> +    const: '/'
> >>>>> +  compatible:
> >>>>> +    oneOf:
> >>>>> +      - description: AMD MicroBlaze V
> >>>>> +        items:
> >>>>> +          - const: amd,mbv
> >>>>
> >>>> You don't actually list any boards here, but instead permit having only
> >>>> the SoC compatible and no board one. The SoC compatible is also
> >>>> incredibly generic. Personally I don't think this binding makes any
> >>>> sense as it appears to exist as a catch all for anything using your
> >>>> new cores in any combination.
> >>>
> >>> I think I need to define any string for compatibility because it is standard
> >>> property. Because this is soft core it can be added to any board with AMD/Xilinx
> >>> chip. I don't have really an option to list all boards.
> >>
> >> Why? Either there is a product with this soft-core or there is not. It
> >> cannot be both.
> > 
> > I am doing basic enablement. I am not making product. Product will be done by 
> > our customers using this core.
> > There will be thousands of different configurations done by customers which will 
> > have products with it. Also there could be hundreds configurations done on the 
> > same board.
> 
> If this is the same board, then why there is compatible for it?
> 
> > 
> > Does it make sense to have board related compatible string like this if this 
> > evaluation board is used by a lot of customers?
> > "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
> 
> I miss the point what is the hardware. Evaluation board is the hardware.
> If someone changes it and makes a new product, it is a new product.

To me, this does actually make (some) sense.
The first compatible is "soc" + board + design.
The second is "soc" + board.
The final one is the "soc".

I say "soc" though, because it is not a single soc - it could be any
configuration of these soft AMD cores on an FPGA in any quality,
possibly set up heterogeneously too. I don't think trying to define a
generic compatible for it like this makes sense as the soc part does
not come close to identifying a specific device.

Until someone actually creates a product that ships with this, I don't
think it makes sense to try and define a binding.

I spoke to Palmer a bit about this, and what I think would make sense is
if you had some sort of "reference design" bitstream that people could
download and run on xyz AMD devkit. If that existed, then we could
document that configuration etc. Otherwise you're in the same spot that
a lot of IP vendor stuff is, where without there being something that
qualifies as "real hardware" using the core, it doesn't make sense to
try and create bindings etc. It's the same for the various people in
the RISC-V community that created their own CPUs that they run on FPGAs.

> > Or I can define qemu one.
> > "amd,qemu-mbv", "amd,mbv"
> 
> QEMU is not hardware, so not.
> 
> > 
> > I think customers should be adding their compatible string in front of generic one.
> 
> To what? To evaluation board? Why?
> 
> > 
> > Years ago I have done the same thing with Microblaze where compatible is defined 
> > as xlnx,microblaze only. 
> 
> Again, what is the use of such binding?
> 
> > When customer take this soft core, put IPs around and 
> > create a product they should extend it to be for example like this.
> > "xyz,my-product-1.0", "xlnx,microblaze";
> 
> So there is a product, not evaluation board.
> 
> > 
> > And over all of years I have never seen any single customer to try to push dt 
> > description for any Microblaze based product.
> > 
> >>>
> >>> I am happy to change it to something else but not sure to what.
> >>
> >> Alone this compatible does not bring you anything.
> > 
> > I don't agree with it. It is standard property and I have to define it somehow.
> 
> The property is already defined, you do not have to define it. What you
> define here is the value for compatible. Why do you need to define it
> somehow? Who asks for that?
> 
> > If not, I get an error.
> > .../xilinx-mbv32.dtb: /: 'compatible' is a required property
> 
> So you have a board? The patches must be linked to each other, e.g.
> preferred way is to send them in one patchset.

There were patches sent to U-Boot for an example configuration:
https://lore.kernel.org/u-boot/d488b7016e0d1b1324c64d8a8b2f033851aab6c6.1699271804.git.michal.simek@amd.com/

> > And it tells me that this risc-v compatible core runs on AMD fpga and it is 
> > compatible with it.

Basically, it provides no more specific information than the cpu node
does. From me, it's a NAK for a compatible like this that that permits
using it in isolation for any core configuration and combination.

Cheers,
Conor.



Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists