Message-ID: <BL1PR18MB424884AB9E0D8E8BF4AD1926DB83A@BL1PR18MB4248.namprd18.prod.outlook.com>
Date:   Wed, 29 Nov 2023 07:41:23 +0000
From:   Elad Nachman <enachman@...vell.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "sebastian.hesselbarth@...il.com" <sebastian.hesselbarth@...il.com>,
        "pali@...nel.org" <pali@...nel.org>,
        "mrkiko.rs@...il.com" <mrkiko.rs@...il.com>,
        "chris.packham@...iedtelesis.co.nz" 
        <chris.packham@...iedtelesis.co.nz>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Yuval Caduri <cyuval@...vell.com>
Subject: RE: [EXT] Re: [PATCH v6 3/3] arm64: dts: cn913x: add device trees for
 COM Express boards



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, November 28, 2023 12:34 AM
> To: Elad Nachman <enachman@...vell.com>
> Cc: robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org;
> conor+dt@...nel.org; gregory.clement@...tlin.com;
> sebastian.hesselbarth@...il.com; pali@...nel.org; mrkiko.rs@...il.com;
> chris.packham@...iedtelesis.co.nz; devicetree@...r.kernel.org; linux-
> kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; Yuval Caduri
> <cyuval@...vell.com>
> Subject: [EXT] Re: [PATCH v6 3/3] arm64: dts: cn913x: add device trees for
> COM Express boards
> 
> External Email
> 
> ----------------------------------------------------------------------
> > +++ b/arch/arm64/boot/dts/marvell/ac5x-rd-carrier-cn9131.dts
> > @@ -0,0 +1,25 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (C) 2023 Marvell International Ltd.
> > + *
> > + * Device tree for the AC5X RD Type 7 Com Express carrier board,
> > + * Utilizing the CN913x COM Express CPU module board.
> > + * This specific board only maintains a PCIe link with the CPU CPU
> > +module
> > + * module, which does not require any special DTS definitions.
> > + */
> > +
> > +#include "cn9131-db-comexpress.dtsi"
> > +#include "ac5x-rd-carrier.dtsi"
> > +
> > +/ {
> > +	model = "Marvell Armada AC5X RD COM EXPRESS type 7 carrier
> board with CN9131 CPU module";
> > +	compatible = "marvell,cn9131-ac5x-carrier", "marvell,rd-ac5x-
> carrier",
> > +			"marvell,cn9131-cpu-module", "marvell,cn9131",
> > +			"marvell,armada-ap807-quad", "marvell,armada-
> ap807";
> 
> > diff --git a/arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi
> > b/arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi
> > new file mode 100644
> > index 000000000000..fd45d5582233
> 
> > +/ {
> > +	model = "Marvell Armada AC5X RD COM EXPRESS type 7 carrier
> board";
> > +	compatible = "marvell,rd-ac5x-carrier";
> 
> Now i'm confused. What does rd mean?
> 
> I would expect RD mean Reference Design, and that is the complete device in
> its box.

AC5X RD can either work as you would expect, as a complete standalone box using the internal CPU, or you can move the switch on the back of the box to "external" mode, and connect via an external cable a kit which would allow it to use an external CPU COM Express module, mounted on top of an interposer kit.

> 
> Yet, here you have RD for the carrier?
> 
> The box itself is called cn9131-ac5x-carrier?
> 
> This makes no sense to me.
> 
> Maybe i'm understanding this all wrong, and its the carrier which you are
> producing a reference design for? The CPU module does not really matter? I

So in this case, once the switch is set to external as explained above, the AC5X RD becomes part of the carrier solution.
This is a development/reference solution, not a full commercial solution, hence it has the flexibility to be configured in different modes of operation.

> could use any off the shelf ComExpress 7 SOM. The bits you are trying to sell

Basically, yes. We have it validated versus few x86_64 system in our labs.

> are on the carrier? But since you are Marvell, you don't want to recommend
> using an AMD ComExpress board when you happen to also have CPU

To the best of my knowledge, we did not validate specifically against AMD COM Express solutions.
Since some of these modules utilize non-standard implementation of the COM Express standard (for example, few AMD CPUs do not have 10G signals, hence few AMD COM Express designs drive PCIe signals via the 10G-KR Ethernet pins of the COM Express standard), it is up to the customer, if he chooses to use such module(s), to validate them against the Marvell AC5X RD, acting as carrier via the interposer kit.

> module which would work? But the CPU is not really the point of this, its the
> carrier?

We have tested and validated a complete reference/development solution combining CN9131 Com Express CPU module, interposer kit and AC5X RD as carrier.
We only push to upstream solutions which we have validated in the lab, hence we push device tree files for the combination tested - specific CPU and specific carrier.
Customers are free to use other COM Express CPU modules, but they will have to validate them by themselves, to account for any deviation from the COM Express standard.
After that, if they wish, they can choose to go for the process of upstreaming their device tree files by their own, like we chose.

> 
> 	Andrew

FYI,

Elad.

Powered by blists - more mailing lists