On Tue, 1 Feb 2022 at 09:00, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Mon, Jan 31, 2022 at 7:52 PM Verdun, Jean-Marie <verdun@xxxxxxx> wrote: > > > > - GXP is the name of the SoC. It has multiple implementations, which are currently compatibles. I don't think for the moment that we need to distinguished them. We might have a GXP v2 coming up but not before a certain amount of time which is far enough. > > - This SoC is used to implement BMC features of HPE servers (all ProLiant, many Apollo, and Superdome machines) > > Is there any more specific name of the chip that can be used to identify the > exact generation after a new one comes out? The normal way we handle > compatible strings for devices is to start with a specific model number of > the chip that integrates it, and then have later chips refer to the device by > its new name, with the old one as a fallback. This makes drivers work out of > the box when the device is unchanged, but gives you a way to distinguish them > if a difference gets noticed after both revisions are already used. > > As with some of points that Krzysztof and others made previously, the goal > here is to avoid binding incompatibilities in the future: anything that works > in an upstream kernel should keep working in later versions, ideally > allowing any combination of old and new dtb blobs in the bootloader > with old or new kernel versions. > > > It does support many features including: > > - ARMv7 architecture, and it is based on a Cortex A9 core > > - Use an AXI bus to which > > - a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII > > - Multiple I2C engines to drive connectivity with a host infrastructure > > - A video engine which support VGA and DP, as well as an hardware video encder > > - Multiple PCIe ports > > - A PECI interface, and LPC eSPI > > - Multiple UART for debug purpose, and Virtual UART for host connectivity > > - A GPIO engine > > Thanks for the description. This seems quite normal then, similar to the > aspeed and npcm BMC platforms that we support already. You can > probably drop some of the people on the Cc list, but I would suggest you add > the openbmc list and Joel Stanley (Cc'd now) in your next submissions, Joel > would be the best person to review the parts that are BMC specific. I had a call with some of the HPE developers a while back. It's good to hear from you again. As Arnd said, please cc me on your submissions and I'll provide review. You can also cc openbmc@xxxxxxxxxxxxxxxx to reach a wider audience of BMC developers. After our call the other month, I took a look at your latest kernel tree and started teasing out something that could be submitted: https://github.com/shenki/linux/commits/gxp Hopefully this helps illustrate what we mean about breaking down the patches into small logical chunks. Don't take what I've done there as correct, but it's an indication. Feel free to re-use. I encourage you to take a look at the aspeed device trees for inspiration. The way they are organised into generations - 2400, 2500, 2600 - illistrate's Arnd's points about supporting multiple generations of SoC with the one code base. Cheers, Joel
