[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] xen/arm: platform: additional Raspberry Pi compatible string
Hi Stewart,
On 9/14/19 2:22 AM, Stewart Hildebrand wrote:
On Friday, September 13, 2019 5:42 PM, Julien Grall <julien.grall@xxxxxxx>
wrote:
Hi,
On 9/13/19 8:11 PM, Stewart Hildebrand wrote:
Upstream Linux kernel will use "brcm,bcm2711" as the compatible string
for Raspberry Pi 4 [1]. Add this string to our platform compatible list
for compatibility with the upstream kernel.
This raises a few questions:
1) Why such discrepancies in naming?
Traditionally the raspberry pi tree has used the bcm2708/9/10 naming
convention, and upstream bcm2835/6/7. It seems they've switched it up for the
RPi4. In the RFC version of the series intended for upstream, they indeed had
it as 2838 [2], but after that it changed to 2711 [3] [4].
The SoC name in documentation is BCM2711 [5] [6].
2) Is the patch [1] merged? If so, which version?
No.
I would rather wait until the patch is merged in Linux before adding the
compatible.
3) Both upstream and non-upstream seem to have the compatible
"raspberrypi,4-model-b", so would it make sense to check that instead?
"raspberrypi,4-model-b" describes a board, and "brcm,bcm2xxx" describes a SoC. It is feasible that
there will be more boards based on this SoC, in which case we'd have to add those hypothetical new boards separately.
If we list both "brcm,bcm2711" and "brcm,bcm2838", then it seems to me we'd have a better chance at
matching future boards with this particular SoC, while also matching both upstream and non-upstream trees.
To be honest, if I knew the compatible would be different between
upstream and non-upstream, I would have NAcked the previous patch.
A Device-Tree is meant to describe the platform in an agnostic-kernel
way. In the ideal world, the device-tree is part shipped with the
firmware. So here, you would have to use a different device-tree
depending on whether you are using upstream or non-upstream kernel.
From Xen PoV, we should really only used stable bindings (i.e accepted
by the kernel community). Anything non-stable are at risk to change in
the future.
Anyway, the RPI community should definitely sort out this mess...
This also raise the question on what's going to happen for blacklist
device? Are they still going to contain "bcm2835"?
static const char *const brcm_bcm2838_dt_compat[] __initconst =
{
+ "brcm,bcm2711",
If a new compatible is added, then you likely need to rename the
different structure within this file.
Good point. Since the documentation uses the BCM2711 convention, it would make
sense to me to rename it reflecting this, even when the list contains both
brcm,bcm2711 and brcm,bcm2838. And perhaps also add a comment by the
brcm,bcm2838 entry to explain the oddity.
I would prefer rpi4_dt_compat as this file is only meant to cover rpi4.
The comment explaining why brcm,brcm2838 is present is good as it hints
this is not an upstream thing.
static const char *const brcm_bcm2711_dt_compat[] __initconst =
{
"brcm,bcm2711",
/*
* While the name of the SoC is BCM2711, some variants of Linux
* have also used the brcm,bcm2838 naming convention. We consider
* either compatible string to be a valid match for the BCM2711 SoC.
*/
"brcm,bcm2838",
The bcm2838 naming convention statement ironically refers to the raspberry pi
tree [7].
[2] RFC https://patchwork.kernel.org/cover/11048215/#22767107
[3] v1 https://patchwork.kernel.org/cover/11051653/
[4] v2 https://patchwork.kernel.org/cover/11092641/
[5]
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/README.md
[6]
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0_preliminary.pdf
[7]
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2711-rpi-4-b.dts#L8
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
