[PATCH v3 2/5] powerpc: apm82181: create shared dtsi for APM bluestone

[Christian Lamparter]

On Tue, Sep 22, 2020 at 9:14 PM Rob Herring <robh at kernel.org> wrote:
>
> On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey at gmail.com> wrote:
> >
> > On 2020-09-15 03:05, Rob Herring wrote:
> > > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote:
> > >> This patch adds an DTSI-File that can be used by various device-tree
> > >> files for APM82181-based devices.
> > >>
> > >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
> > >> need to stick with the naming-conventions of the old times'.
> > >> I've added comments whenever this was the case.
> > >>
> > >> Signed-off-by: Chris Blake <chrisrblake93 at gmail.com>
> > >> Signed-off-by: Christian Lamparter <chunkeey at gmail.com>
> > >> ---
> > >> rfc v1 -> v2:
> > >>      - removed PKA (this CryptoPU will need driver)
> > >>      - stick with compatibles, nodes, ... from either
> > >>        Bluestone (APM82181) or Canyonlands (PPC460EX).
> > >>      - add labels for NAND and NOR to help with access.
> > >> v2 -> v3:
> > >>      - nodename of pciex at d.... was changed to pcie at d..
> > >>        due to upstream patch.
> > >>      - use simple-bus on the ebc, opb and plb nodes
> > >> ---
> > >>   arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++
> > >>   1 file changed, 466 insertions(+)
> > >>   create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
> > >>
> > >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> new file mode 100644
> > >> index 000000000000..60283430978d
> > >> --- /dev/null
> > >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi
> > >> @@ -0,0 +1,466 @@
> > >> +// SPDX-License-Identifier: GPL-2.0-or-later
> > >> +/*
> > >> + * Device Tree template include for various APM82181 boards.
> > >> + *
> > >> + * The SoC is an evolution of the PPC460EX predecessor.
> > >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB,
> > >> + * DMA, SATA, EMAC, ... ended up in here.
> > >> + *
> > >> + * Copyright (c) 2010, Applied Micro Circuits Corporation
> > >> + * Author: Tirumala R Marri <tmarri at apm.com>,
> > >> + *     Christian Lamparter <chunkeey at gmail.com>,
> > >> + *     Chris Blake <chrisrblake93 at gmail.com>
> > >> + */
> > >> +
> > >> +#include <dt-bindings/dma/dw-dmac.h>
> > >> +#include <dt-bindings/input/input.h>
> > >> +#include <dt-bindings/interrupt-controller/irq.h>
> > >> +#include <dt-bindings/gpio/gpio.h>
> > >> +
> > >> +/ {
> > >> +    #address-cells = <2>;
> > >> +    #size-cells = <1>;
> > >> +    dcr-parent = <&{/cpus/cpu at 0}>;
> > >> +
> > >> +    aliases {
> > >> +            ethernet0 = &EMAC0; /* needed for BSP u-boot */
> > >> +    };
> > >> +
> > >> +    cpus {
> > >> +            #address-cells = <1>;
> > >> +            #size-cells = <0>;
> > >> +
> > >> +            CPU0: cpu at 0 {
> > >> +                    device_type = "cpu";
> > >> +                    model = "PowerPC,apm82181";
> > >
> > > This doesn't match the existing bluestone dts file.
> > >
> > > Please separate any restructuring from changes.
> >
> >
> > "I see" (I'm including your comment of the dt-binding as well).
> >
> > I'm getting the vibe that I better should not touch that bluestone.dts.
>
> I don't know about that.

k, understood.

>
> > An honestly, looking at the series and patches that the APM-engineers
> > posted back in the day, I can see why this well is so poisoned... and
> > stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing.
> >
> > As for the devices. In the spirit of Arnd Bergmann's post of
> > <https://lkml.org/lkml/2020/3/30/195>
> >
> > |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file
> > |when that gets added, if only to ensure they use the same description for each
> > |node, but that shouldn't stop the addition of the new file if that is needed for
> > |distros to make use of a popular device.
> > |I see a couple of additional files in openwrt.
> >
> > I mean I don't have the bluestone dev board, just the consumer devices.
>
> This stuff is old enough, I'd guess no one cares about a dev board.
> But we should figure that out and document that with any changes.
>
> > Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi
> > This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller),
> > the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram".
>
> This skeleton would be chunks moved over or duplicated? I don't think
> we want 2 of the same thing.
My Idea was copying the working apm82181.dtsi we have in OpenWrt
and stripping the nodes we added for SATA, USB, GPIO and the likes.
so the remaining nodes would be very close to what bluestone.dts had.
The main differences would be:
- It's a bit smaller since I made a separate patch for the NOR/NAND on the EBC.
Reason being that the SoC uses glue-logic for mapping NOR/NAND (and other
external peripherals like the GPIOs on the WD) into the memory and I thought
this needed some explanation as to why this weird thing works.

- it would already use the dt-bindings/interrupt-controller/irq.h macros
for LEVEL/EDGE cell values

- it contains valuable comments about the uboot. Because ethernet0 alias
  and the /plb/obc/ebc node-name requirements).

- UART are using 16750 compatible (as per hardware docs)

>
> The order I would go is split into an apm82181.dtsi with 0 changes to
> the built dtb(s). Then make changes/additions you need. As far as
> changes to existing bindings, it's only an ABI if someone notices.

This will rewriting the history,  as the development of apm82181.dtsi
did happen differently (basically, each device started with its own full dts.
But early on in 2016 we merged the common nodes and switched over
to the macros). This is fine though, I'll need some time to rebase and rewrite
the patches.

(Note: I've already wrote a patch for a the apm82181 dwc USB binding for
this: <https://www.spinics.net/lists/devicetree/msg378884.html>. Not sure
about uic, sata and dw-dma as these drivers each use a common binding.
I hope there's some leeway for this old stuff.)

Cheers,
Christian