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@xxxxxxxxx>
> ---
> 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@xxxxxxxxx>
>
