The BCM21664 and BCM23550 are nearly identical to each other in terms
of register layout. This was verified against a downstream kernel[1] -
Broadcom's kernel has "RDB" directories which includes headers with
the full register maps for the included hardware. Running:

  diff --recursive arch/arm/mach-{hawaii,java}/include/mach/rdb

reveals that the differences are minuscule - some things related to
ISP and H264 decoding. Most of the other differences are related to
the different CPUs in the two chipsets - the BCM21664 has 2x Cortex-A9
cores, and the BCM23550 has 4x Cortex-A7 cores.

In mainline, most drivers are also re-used between the two.

To make development for both platforms easier, split out the common
nodes into a separate DTSI, bcm21664-common.dtsi. This only leaves
the device-specific nodes - so, CPU and related things - in the SoC-
specific DTSIs (bcm21664.dtsi and bcm23550.dtsi).

The new DTSI is based off the bcm23550.dtsi, with its split into
busses. Since it's pretty much 99% identical, I kept the licensing
of the original file (BSD 3-clause). The license for the bcm21664.dtsi
file remains GPL 2.0 as it originally was.

make CHECK_DTBS=y on bcm21664-garnet.dtb and bcm23550-sparrow.dtb
seem to pass fine for me (thanks to Stanislav Jakubek for converting
the bindings to YAML format!). It's worth noting though that some
bcm23550 compatibles now go unused, since the bcm21664-common.dtsi
file uses bcm21664 compatibles.

[1] https://github.com/knuxdroid/android_kernel_samsung_baffinlite

Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
---
Artur Weber (2):
      ARM: dts: broadcom: bcm21664: Move chosen node into bcm21664-garnet DTS
      ARM: dts: bcm-mobile: Split out nodes used by both BCM21664 and BCM23550

 arch/arm/boot/dts/broadcom/bcm21664-common.dtsi | 334 ++++++++++++++++++++++
 arch/arm/boot/dts/broadcom/bcm21664-garnet.dts  |   4 +
 arch/arm/boot/dts/broadcom/bcm21664.dtsi        | 326 +---------------------
 arch/arm/boot/dts/broadcom/bcm23550.dtsi        | 354 +-----------------------
 4 files changed, 357 insertions(+), 661 deletions(-)
---
base-commit: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
change-id: 20240528-bcm21664-common-14064864a4a7

Best regards,
-- 
Artur Weber <aweber.kernel@gmail.com>

Hi Artur,

thanks for the patches! Some notes below.

On Wed, Jun 05, 2024 at 08:40:11AM +0200, Artur Weber wrote:
> The BCM21664 and BCM23550 are nearly identical to each other in terms
> of register layout. This was verified against a downstream kernel[1] -
> Broadcom's kernel has "RDB" directories which includes headers with
> the full register maps for the included hardware. Running:
> 
>   diff --recursive arch/arm/mach-{hawaii,java}/include/mach/rdb
> 
> reveals that the differences are minuscule - some things related to
> ISP and H264 decoding. Most of the other differences are related to
> the different CPUs in the two chipsets - the BCM21664 has 2x Cortex-A9
> cores, and the BCM23550 has 4x Cortex-A7 cores.
> 
> In mainline, most drivers are also re-used between the two.
> 
> To make development for both platforms easier, split out the common
> nodes into a separate DTSI, bcm21664-common.dtsi. This only leaves
> the device-specific nodes - so, CPU and related things - in the SoC-
> specific DTSIs (bcm21664.dtsi and bcm23550.dtsi).

The name "bcm21664-common" makes me think that it's a DTSI for common
properties of multiple BCM21664 *board* DTs, which is obviously not the
case here. IMO something like "bcm21664-bcm23550-common" makes more sense here.

> 
> The new DTSI is based off the bcm23550.dtsi, with its split into
> busses. Since it's pretty much 99% identical, I kept the licensing
> of the original file (BSD 3-clause). The license for the bcm21664.dtsi
> file remains GPL 2.0 as it originally was.
> 
> make CHECK_DTBS=y on bcm21664-garnet.dtb and bcm23550-sparrow.dtb
> seem to pass fine for me (thanks to Stanislav Jakubek for converting
> the bindings to YAML format!).

:)

> It's worth noting though that some bcm23550 compatibles now go unused,
> since the bcm21664-common.dtsi file uses bcm21664 compatibles.

I don't think this is the way to go. While in these cases the Linux drivers
match only on the generic brcm,kona-* fallback compatible (AFAIK anyway),
the compatibles in DT should still be (SoC-)specific.

I think the common DTSI should omit the compatible values altogether
and instead have the compatible be specified in SoC DTSI. You could keep
a note in the common DTSI saying that the compatible is in SoC DTSI or
something similar.

For example:
- in bcm21664-bcm23550-common.dtsi (or whatever we decide to call it):

gpio: gpio@100300 {
	/* compatible is SoC-specific */
	reg = <0x100300 0x524>;
	...
};

- in bcm21664.dtsi:

&gpio {
	compatible = "brcm,bcm21664-gpio", "brcm,kona-gpio";
};

- in bcm23550.dtsi:

&gpio {
	compatible = "brcm,bcm23550-gpio", "brcm,kona-gpio";
};

Regards,
Stanislav

> 
> [1] https://github.com/knuxdroid/android_kernel_samsung_baffinlite
> 
> Signed-off-by: Artur Weber <aweber.kernel@gmail.com>
> ---
> Artur Weber (2):
>       ARM: dts: broadcom: bcm21664: Move chosen node into bcm21664-garnet DTS
>       ARM: dts: bcm-mobile: Split out nodes used by both BCM21664 and BCM23550
> 
>  arch/arm/boot/dts/broadcom/bcm21664-common.dtsi | 334 ++++++++++++++++++++++
>  arch/arm/boot/dts/broadcom/bcm21664-garnet.dts  |   4 +
>  arch/arm/boot/dts/broadcom/bcm21664.dtsi        | 326 +---------------------
>  arch/arm/boot/dts/broadcom/bcm23550.dtsi        | 354 +-----------------------
>  4 files changed, 357 insertions(+), 661 deletions(-)
> ---
> base-commit: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
> change-id: 20240528-bcm21664-common-14064864a4a7
> 
> Best regards,
> -- 
> Artur Weber <aweber.kernel@gmail.com>
>

On 8.06.2024 15:06, Stanislav Jakubek wrote:
>> To make development for both platforms easier, split out the common
>> nodes into a separate DTSI, bcm21664-common.dtsi. This only leaves
>> the device-specific nodes - so, CPU and related things - in the SoC-
>> specific DTSIs (bcm21664.dtsi and bcm23550.dtsi).
> 
> The name "bcm21664-common" makes me think that it's a DTSI for common
> properties of multiple BCM21664 *board* DTs, which is obviously not the
> case here. IMO something like "bcm21664-bcm23550-common" makes more sense here.
> 
The "bcm21664-common" name sounds fine to me, though I can certainly see
how it could be interpreted as a board DTSI (I was planning to make a
bcm21664-samsung-common.dtsi for Samsung's BCM21664-based phones, funny
enough...)

The idea of just putting together the two model numbers sounded a bit
awkward to me at first, but I've been thinking about it and I'm starting
to warm up to it. There are a handful of examples of a similar double-
naming scheme: e.g. intel-ixp45x-ixp46x.dtsi, sunxi-h3-h5.dtsi, sun8i-
a23-a33.dtsi. The difference is that these DTSIs have a manufacturer
prefix and no "-common" suffix.

I had many ideas for naming the common DTSI. My initial idea was
"bcm216xx.dtsi", but that would cover the BCM21654 (which has a few more
differences); then "bcm2166x.dtsi" which would cover the BCM21663 and
BCM21664 (which AFAIK are largely the same). We could combine it with
the current name and get "bcm2166x-common.dtsi". That already sounds
less like a board file to me, what do you think?

>> It's worth noting though that some bcm23550 compatibles now go unused,
>> since the bcm21664-common.dtsi file uses bcm21664 compatibles.
> 
> I don't think this is the way to go. While in these cases the Linux drivers
> match only on the generic brcm,kona-* fallback compatible (AFAIK anyway),
> the compatibles in DT should still be (SoC-)specific.
> 
> I think the common DTSI should omit the compatible values altogether
> and instead have the compatible be specified in SoC DTSI. You could keep
> a note in the common DTSI saying that the compatible is in SoC DTSI or
> something similar.

There's plenty of DTSIs in the kernel that have "device-specific"
compatibles in common DTSIs. Off the top of my head I can name the
Exynos 4 DTSIs that do this pretty often[1][2][3] (4210 and 4212
compatibles in DTSIs that are later included from the 4412 DTSI, but
which does not override any of them).

While looking around for examples I stumbled upon some sunxi DTSIs that
actually do *both*: have some compatibles that mention one of the two
models they cover, but leave some compatibles to be set in the child
DTSIs[4][5].

Since as I mentioned the underlying components seem to be the exact
same, the compatibles are really just cosmetic; plus I feel like lots of
such compatible-only nodes could add unnecessary noise to the SoC DTSIs.

With that said, I'm not against the idea, and I suppose it's not too
much extra work. I'm curious what other reviewers will have to say, but
either way I'll try to incorporate this into the next version of this
patchset.

Best regards
Artur

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4.dtsi
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4x12.dtsi
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/samsung/exynos4412.dtsi
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sunxi-h3-h5.dtsi
[5] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun8i-a23-a33.dtsi

On 5.06.2024 08:40, Artur Weber wrote:
> The BCM21664 and BCM23550 are nearly identical to each other in terms
> of register layout. This was verified against a downstream kernel[1] -

Let me rephrase this a bit, since upon reading it again it kind of
sounds like this means "subdevices are in the same place". I mean that
literally many of the components are the exact same, 1:1, and the same
drivers with the same configuration will work for both of them. (And
if they turn out to not work, it's as easy as switching the
compatibles/tweaking the SoC-specific DTS.)

If you check the RDB files I linked, they contain the exact layout of
not just the system in general, but each of the individual components
(see for example [1]). These RDB files are called back to multiple times
through the kernel (for example [2]).

Clocks are a notable example of this; if you were to diff the clock
drivers in the kernel I linked in the replied-to message:

   diff arch/arm/mach-{hawaii,java}/clock.c

The only differences are some clocks in the KPROC CCU, and the addition
of a MM2 CCU on the BCM23550. (Note that neither of these two CCUs are
supported in mainline at the moment; I have some WIP series to start
adding the KPROC CCU, but it's still an early work-in-progress.)

Most other drivers (sdio, serial, i2c, and so on) have no differences,
as far as I can tell. And they already use the same drivers in mainline.

Best regards
Artur

[1] https://github.com/knuxdroid/android_kernel_samsung_baffinlite/blob/cm-12.1/arch/arm/mach-hawaii/include/mach/rdb/brcm_rdb_kpm_clk_mgr_reg.h
[2] https://github.com/knuxdroid/android_kernel_samsung_baffinlite/blob/cm-12.1/arch/arm/mach-hawaii/clock.c#L4009-L4055