[PATCH v3 0/4] Improve VCHIQ cache line size handling

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

Both sides of the VCHIQ communications mechanism need to agree on the cache
line size. Using an incorrect value can lead to data corruption, but having the
two sides using different values is usually worse.

In the absence of an obvious convenient run-time method to determine the
correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
Device Tree property, written by the firmware, to configure the kernel driver.
This method was vetoed during the upstreaming process, so a fixed value of 32
was used instead, and some corruptions ensued. This is take 2 at arriving at
the correct value.

Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
a 64-byte cache line. Document the new string in the binding, and use it on
the appropriate platforms.

The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
declaration for the device node, but it doubles as an indication to the
Raspberry Pi firmware that the kernel driver is running a recent kernel driver
that chooses the correct value. As such it would help if the DT patches are
not merged before the driver patch.

v3: Builds without errors, tested on multiple Raspberry Pi models.
v2: Replaced ARM-specific logic used to determine cache line size with
    a new compatible string for BCM2836 and BCM2837.

Phil Elwell (4):
  staging/vc04_services: Use correct cache line size
  dt-bindings: soc: Document "brcm,bcm2836-vchiq"
  ARM: dts: bcm283x: Correct vchiq compatible string
  ARM: dts: bcm283x: Correct mailbox register sizes

 .../bindings/soc/bcm/brcm,bcm2835-vchiq.txt        |  3 +-
 arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  4 +--
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts              |  2 +-
 arch/arm/boot/dts/bcm2836-rpi.dtsi                 |  6 ++++
 arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts         |  2 +-
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts              |  2 +-
 arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi             |  2 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c           |  4 ++-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 35 +++++++++++++++-------
 .../vc04_services/interface/vchiq_arm/vchiq_arm.h  |  5 ++++
 10 files changed, 47 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi

-- 
2.7.4

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

Both sides of the VCHIQ communications mechanism need to agree on the cache
line size. Using an incorrect value can lead to data corruption, but having the
two sides using different values is usually worse.

In the absence of an obvious convenient run-time method to determine the
correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
Device Tree property, written by the firmware, to configure the kernel driver.
This method was vetoed during the upstreaming process, so a fixed value of 32
was used instead, and some corruptions ensued. This is take 2 at arriving at
the correct value.

Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
a 64-byte cache line. Document the new string in the binding, and use it on
the appropriate platforms.

The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
declaration for the device node, but it doubles as an indication to the
Raspberry Pi firmware that the kernel driver is running a recent kernel driver
that chooses the correct value. As such it would help if the DT patches are
not merged before the driver patch.

v3: Builds without errors, tested on multiple Raspberry Pi models.
v2: Replaced ARM-specific logic used to determine cache line size with
    a new compatible string for BCM2836 and BCM2837.

Phil Elwell (4):
  staging/vc04_services: Use correct cache line size
  dt-bindings: soc: Document "brcm,bcm2836-vchiq"
  ARM: dts: bcm283x: Correct vchiq compatible string
  ARM: dts: bcm283x: Correct mailbox register sizes

 .../bindings/soc/bcm/brcm,bcm2835-vchiq.txt        |  3 +-
 arch/arm/boot/dts/bcm2835-rpi.dtsi                 |  4 +--
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts              |  2 +-
 arch/arm/boot/dts/bcm2836-rpi.dtsi                 |  6 ++++
 arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts         |  2 +-
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts              |  2 +-
 arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi             |  2 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c           |  4 ++-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 35 +++++++++++++++-------
 .../vc04_services/interface/vchiq_arm/vchiq_arm.h  |  5 ++++
 10 files changed, 47 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi

-- 
2.7.4

[PATCH v3 1/4] staging/vc04_services: Use correct cache line size

[Phil Elwell]

Use the compatible string in the DTB to select the correct cache line
size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
 .../interface/vchiq_arm/vchiq_2835_arm.c           |  4 ++-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 35 +++++++++++++++-------
 .../vc04_services/interface/vchiq_arm/vchiq_arm.h  |  5 ++++
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index e767209..83d740f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -109,7 +109,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 {
 	struct device *dev = &pdev->dev;
-	struct rpi_firmware *fw = platform_get_drvdata(pdev);
+	struct vchiq_drvdata *drvdata = platform_get_drvdata(pdev);
+	struct rpi_firmware *fw = drvdata->fw;
 	VCHIQ_SLOT_ZERO_T *vchiq_slot_zero;
 	struct resource *res;
 	void *slot_mem;
@@ -127,6 +128,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 	if (err < 0)
 		return err;
 
+	g_cache_line_size = drvdata->cache_line_size;
 	g_fragments_size = 2 * g_cache_line_size;
 
 	/* Allocate space for the channels in coherent memory */
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index bc05c69..ea78937 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -170,6 +170,14 @@ static struct device *vchiq_dev;
 static DEFINE_SPINLOCK(msg_queue_spinlock);
 static struct platform_device *bcm2835_camera;
 
+static struct vchiq_drvdata bcm2835_drvdata = {
+	.cache_line_size = 32,
+};
+
+static struct vchiq_drvdata bcm2836_drvdata = {
+	.cache_line_size = 64,
+};
+
 static const char *const ioctl_names[] = {
 	"CONNECT",
 	"SHUTDOWN",
@@ -3573,12 +3581,25 @@ void vchiq_platform_conn_state_changed(VCHIQ_STATE_T *state,
 	}
 }
 
+static const struct of_device_id vchiq_of_match[] = {
+	{ .compatible = "brcm,bcm2835-vchiq", .data = &bcm2835_drvdata },
+	{ .compatible = "brcm,bcm2836-vchiq", .data = &bcm2836_drvdata },
+	{},
+};
+MODULE_DEVICE_TABLE(of, vchiq_of_match);
+
 static int vchiq_probe(struct platform_device *pdev)
 {
 	struct device_node *fw_node;
-	struct rpi_firmware *fw;
+	const struct of_device_id *of_id;
+	struct vchiq_drvdata *drvdata;
 	int err;
 
+	of_id = of_match_node(vchiq_of_match, pdev->dev.of_node);
+	drvdata = (struct vchiq_drvdata *)of_id->data;
+	if (!drvdata)
+		return -EINVAL;
+
 	fw_node = of_find_compatible_node(NULL, NULL,
 					  "raspberrypi,bcm2835-firmware");
 	if (!fw_node) {
@@ -3586,12 +3607,12 @@ static int vchiq_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	fw = rpi_firmware_get(fw_node);
+	drvdata->fw = rpi_firmware_get(fw_node);
 	of_node_put(fw_node);
-	if (!fw)
+	if (!drvdata->fw)
 		return -EPROBE_DEFER;
 
-	platform_set_drvdata(pdev, fw);
+	platform_set_drvdata(pdev, drvdata);
 
 	err = vchiq_platform_init(pdev, &g_state);
 	if (err != 0)
@@ -3661,12 +3682,6 @@ static int vchiq_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id vchiq_of_match[] = {
-	{ .compatible = "brcm,bcm2835-vchiq", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, vchiq_of_match);
-
 static struct platform_driver vchiq_driver = {
 	.driver = {
 		.name = "bcm2835_vchiq",
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
index 40bb0c6..2f3ebc9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
@@ -123,6 +123,11 @@ typedef struct vchiq_arm_state_struct {
 
 } VCHIQ_ARM_STATE_T;
 
+struct vchiq_drvdata {
+	const unsigned int cache_line_size;
+	struct rpi_firmware *fw;
+};
+
 extern int vchiq_arm_log_level;
 extern int vchiq_susp_log_level;
 
-- 
2.7.4

[PATCH v3 1/4] staging/vc04_services: Use correct cache line size

[Phil Elwell]

Use the compatible string in the DTB to select the correct cache line
size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
 .../interface/vchiq_arm/vchiq_2835_arm.c           |  4 ++-
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 35 +++++++++++++++-------
 .../vc04_services/interface/vchiq_arm/vchiq_arm.h  |  5 ++++
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index e767209..83d740f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -109,7 +109,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 {
 	struct device *dev = &pdev->dev;
-	struct rpi_firmware *fw = platform_get_drvdata(pdev);
+	struct vchiq_drvdata *drvdata = platform_get_drvdata(pdev);
+	struct rpi_firmware *fw = drvdata->fw;
 	VCHIQ_SLOT_ZERO_T *vchiq_slot_zero;
 	struct resource *res;
 	void *slot_mem;
@@ -127,6 +128,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 	if (err < 0)
 		return err;
 
+	g_cache_line_size = drvdata->cache_line_size;
 	g_fragments_size = 2 * g_cache_line_size;
 
 	/* Allocate space for the channels in coherent memory */
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index bc05c69..ea78937 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -170,6 +170,14 @@ static struct device *vchiq_dev;
 static DEFINE_SPINLOCK(msg_queue_spinlock);
 static struct platform_device *bcm2835_camera;
 
+static struct vchiq_drvdata bcm2835_drvdata = {
+	.cache_line_size = 32,
+};
+
+static struct vchiq_drvdata bcm2836_drvdata = {
+	.cache_line_size = 64,
+};
+
 static const char *const ioctl_names[] = {
 	"CONNECT",
 	"SHUTDOWN",
@@ -3573,12 +3581,25 @@ void vchiq_platform_conn_state_changed(VCHIQ_STATE_T *state,
 	}
 }
 
+static const struct of_device_id vchiq_of_match[] = {
+	{ .compatible = "brcm,bcm2835-vchiq", .data = &bcm2835_drvdata },
+	{ .compatible = "brcm,bcm2836-vchiq", .data = &bcm2836_drvdata },
+	{},
+};
+MODULE_DEVICE_TABLE(of, vchiq_of_match);
+
 static int vchiq_probe(struct platform_device *pdev)
 {
 	struct device_node *fw_node;
-	struct rpi_firmware *fw;
+	const struct of_device_id *of_id;
+	struct vchiq_drvdata *drvdata;
 	int err;
 
+	of_id = of_match_node(vchiq_of_match, pdev->dev.of_node);
+	drvdata = (struct vchiq_drvdata *)of_id->data;
+	if (!drvdata)
+		return -EINVAL;
+
 	fw_node = of_find_compatible_node(NULL, NULL,
 					  "raspberrypi,bcm2835-firmware");
 	if (!fw_node) {
@@ -3586,12 +3607,12 @@ static int vchiq_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	fw = rpi_firmware_get(fw_node);
+	drvdata->fw = rpi_firmware_get(fw_node);
 	of_node_put(fw_node);
-	if (!fw)
+	if (!drvdata->fw)
 		return -EPROBE_DEFER;
 
-	platform_set_drvdata(pdev, fw);
+	platform_set_drvdata(pdev, drvdata);
 
 	err = vchiq_platform_init(pdev, &g_state);
 	if (err != 0)
@@ -3661,12 +3682,6 @@ static int vchiq_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id vchiq_of_match[] = {
-	{ .compatible = "brcm,bcm2835-vchiq", },
-	{},
-};
-MODULE_DEVICE_TABLE(of, vchiq_of_match);
-
 static struct platform_driver vchiq_driver = {
 	.driver = {
 		.name = "bcm2835_vchiq",
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
index 40bb0c6..2f3ebc9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.h
@@ -123,6 +123,11 @@ typedef struct vchiq_arm_state_struct {
 
 } VCHIQ_ARM_STATE_T;
 
+struct vchiq_drvdata {
+	const unsigned int cache_line_size;
+	struct rpi_firmware *fw;
+};
+
 extern int vchiq_arm_log_level;
 extern int vchiq_susp_log_level;
 
-- 
2.7.4

[PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

[Phil Elwell]

"brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure
correct operation.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
index 8dd7b3a..f331316 100644
--- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
@@ -2,7 +2,8 @@ Broadcom VCHIQ firmware services
 
 Required properties:
 
-- compatible:	Should be "brcm,bcm2835-vchiq"
+- compatible:	Should be "brcm,bcm2835-vchiq" on BCM2835, otherwise
+		"brcm,bcm2836-vchiq".
 - reg:		Physical base address and length of the doorbell register pair
 - interrupts:	The interrupt number
 		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- 
2.7.4

[PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

[Phil Elwell]

"brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure
correct operation.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
index 8dd7b3a..f331316 100644
--- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
+++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt
@@ -2,7 +2,8 @@ Broadcom VCHIQ firmware services
 
 Required properties:
 
-- compatible:	Should be "brcm,bcm2835-vchiq"
+- compatible:	Should be "brcm,bcm2835-vchiq" on BCM2835, otherwise
+		"brcm,bcm2836-vchiq".
 - reg:		Physical base address and length of the doorbell register pair
 - interrupts:	The interrupt number
 		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- 
2.7.4

[PATCH v3 3/4] ARM: dts: bcm283x: Correct vchiq compatible string

[Phil Elwell]

To allow VCHIQ to determine the correct cache line size, use the new
"brcm,bcm2836-vchiq" compatible string on BCM2836 and BCM2837.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi         | 2 +-
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts      | 2 +-
 arch/arm/boot/dts/bcm2836-rpi.dtsi         | 6 ++++++
 arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 2 +-
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts      | 2 +-
 arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi     | 2 +-
 6 files changed, 11 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index cb2d6d7..215d8cc 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -30,7 +30,7 @@
 			#power-domain-cells = <1>;
 		};
 
-		mailbox@7e00b840 {
+		vchiq: mailbox@7e00b840 {
 			compatible = "brcm,bcm2835-vchiq";
 			reg = <0x7e00b840 0xf>;
 			interrupts = <0 2>;
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 2fef70a..ac4408b 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2836.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-smsc9514.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
new file mode 100644
index 0000000..c4c858b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "bcm2835-rpi.dtsi"
+
+&vchiq {
+	compatible = "brcm,bcm2836-vchiq", "brcm,bcm2835-vchiq";
+};
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
index 4adb85e..eca36e3 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-lan7515.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index c318bcb..a0ba0f6 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-smsc9514.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
index 7b7ab6a..4a89a18 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
+++ b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 
 / {
 	memory {
-- 
2.7.4

[PATCH v3 3/4] ARM: dts: bcm283x: Correct vchiq compatible string

[Phil Elwell]

To allow VCHIQ to determine the correct cache line size, use the new
"brcm,bcm2836-vchiq" compatible string on BCM2836 and BCM2837.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi         | 2 +-
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts      | 2 +-
 arch/arm/boot/dts/bcm2836-rpi.dtsi         | 6 ++++++
 arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 2 +-
 arch/arm/boot/dts/bcm2837-rpi-3-b.dts      | 2 +-
 arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi     | 2 +-
 6 files changed, 11 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2836-rpi.dtsi

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index cb2d6d7..215d8cc 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -30,7 +30,7 @@
 			#power-domain-cells = <1>;
 		};
 
-		mailbox at 7e00b840 {
+		vchiq: mailbox at 7e00b840 {
 			compatible = "brcm,bcm2835-vchiq";
 			reg = <0x7e00b840 0xf>;
 			interrupts = <0 2>;
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 2fef70a..ac4408b 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2836.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-smsc9514.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2836-rpi.dtsi b/arch/arm/boot/dts/bcm2836-rpi.dtsi
new file mode 100644
index 0000000..c4c858b
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "bcm2835-rpi.dtsi"
+
+&vchiq {
+	compatible = "brcm,bcm2836-vchiq", "brcm,bcm2835-vchiq";
+};
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
index 4adb85e..eca36e3 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-lan7515.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index c318bcb..a0ba0f6 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 #include "bcm283x-rpi-smsc9514.dtsi"
 #include "bcm283x-rpi-usb-host.dtsi"
 
diff --git a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
index 7b7ab6a..4a89a18 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
+++ b/arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 #include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
+#include "bcm2836-rpi.dtsi"
 
 / {
 	memory {
-- 
2.7.4

[PATCH v3 4/4] ARM: dts: bcm283x: Correct mailbox register sizes

[Phil Elwell]

The size field in a Device Tree "reg" property is encoded in bytes, not
words.

Fixes: 614fa22119d6 ("ARM: dts: bcm2835: Add VCHIQ node to the Raspberry Pi boards. (v3)")
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 215d8cc..29f970f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -32,7 +32,7 @@
 
 		vchiq: mailbox@7e00b840 {
 			compatible = "brcm,bcm2835-vchiq";
-			reg = <0x7e00b840 0xf>;
+			reg = <0x7e00b840 0x3c>;
 			interrupts = <0 2>;
 		};
 	};
-- 
2.7.4

[PATCH v3 4/4] ARM: dts: bcm283x: Correct mailbox register sizes

[Phil Elwell]

The size field in a Device Tree "reg" property is encoded in bytes, not
words.

Fixes: 614fa22119d6 ("ARM: dts: bcm2835: Add VCHIQ node to the Raspberry Pi boards. (v3)")
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 215d8cc..29f970f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -32,7 +32,7 @@
 
 		vchiq: mailbox at 7e00b840 {
 			compatible = "brcm,bcm2835-vchiq";
-			reg = <0x7e00b840 0xf>;
+			reg = <0x7e00b840 0x3c>;
 			interrupts = <0 2>;
 		};
 	};
-- 
2.7.4

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

[Stefan Wahren]

Hi Phil,

Am 17.09.2018 um 10:22 schrieb Phil Elwell:
> Both sides of the VCHIQ communications mechanism need to agree on the cache
> line size. Using an incorrect value can lead to data corruption, but having the
> two sides using different values is usually worse.
>
> In the absence of an obvious convenient run-time method to determine the
> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
> Device Tree property, written by the firmware, to configure the kernel driver.
> This method was vetoed during the upstreaming process, so a fixed value of 32
> was used instead, and some corruptions ensued. This is take 2 at arriving at
> the correct value.
>
> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
> a 64-byte cache line. Document the new string in the binding, and use it on
> the appropriate platforms.
>
> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
> declaration for the device node, but it doubles as an indication to the
> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
> that chooses the correct value. As such it would help if the DT patches are
> not merged before the driver patch.
>
> v3: Builds without errors, tested on multiple Raspberry Pi models.
> v2: Replaced ARM-specific logic used to determine cache line size with
>     a new compatible string for BCM2836 and BCM2837.
>
> Phil Elwell (4):
>   staging/vc04_services: Use correct cache line size
>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>   ARM: dts: bcm283x: Correct vchiq compatible string
>   ARM: dts: bcm283x: Correct mailbox register sizes

since my pull requests are out, would it be okay to apply patch #1 for
4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
these patches)?

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Stefan Wahren]

Hi Phil,

Am 17.09.2018 um 10:22 schrieb Phil Elwell:
> Both sides of the VCHIQ communications mechanism need to agree on the cache
> line size. Using an incorrect value can lead to data corruption, but having the
> two sides using different values is usually worse.
>
> In the absence of an obvious convenient run-time method to determine the
> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
> Device Tree property, written by the firmware, to configure the kernel driver.
> This method was vetoed during the upstreaming process, so a fixed value of 32
> was used instead, and some corruptions ensued. This is take 2 at arriving at
> the correct value.
>
> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
> a 64-byte cache line. Document the new string in the binding, and use it on
> the appropriate platforms.
>
> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
> declaration for the device node, but it doubles as an indication to the
> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
> that chooses the correct value. As such it would help if the DT patches are
> not merged before the driver patch.
>
> v3: Builds without errors, tested on multiple Raspberry Pi models.
> v2: Replaced ARM-specific logic used to determine cache line size with
>     a new compatible string for BCM2836 and BCM2837.
>
> Phil Elwell (4):
>   staging/vc04_services: Use correct cache line size
>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>   ARM: dts: bcm283x: Correct vchiq compatible string
>   ARM: dts: bcm283x: Correct mailbox register sizes

since my pull requests are out, would it be okay to apply patch #1 for
4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
these patches)?

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

Hi Stefan,

On 17/09/2018 12:39, Stefan Wahren wrote:
> Hi Phil,
> 
> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>> line size. Using an incorrect value can lead to data corruption, but having the
>> two sides using different values is usually worse.
>>
>> In the absence of an obvious convenient run-time method to determine the
>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>> Device Tree property, written by the firmware, to configure the kernel driver.
>> This method was vetoed during the upstreaming process, so a fixed value of 32
>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>> the correct value.
>>
>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>> a 64-byte cache line. Document the new string in the binding, and use it on
>> the appropriate platforms.
>>
>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>> declaration for the device node, but it doubles as an indication to the
>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>> that chooses the correct value. As such it would help if the DT patches are
>> not merged before the driver patch.
>>
>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>> v2: Replaced ARM-specific logic used to determine cache line size with
>>     a new compatible string for BCM2836 and BCM2837.
>>
>> Phil Elwell (4):
>>   staging/vc04_services: Use correct cache line size
>>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>   ARM: dts: bcm283x: Correct vchiq compatible string
>>   ARM: dts: bcm283x: Correct mailbox register sizes
> 
> since my pull requests are out, would it be okay to apply patch #1 for
> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
> these patches)?

Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.

Phil

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

Hi Stefan,

On 17/09/2018 12:39, Stefan Wahren wrote:
> Hi Phil,
> 
> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>> line size. Using an incorrect value can lead to data corruption, but having the
>> two sides using different values is usually worse.
>>
>> In the absence of an obvious convenient run-time method to determine the
>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>> Device Tree property, written by the firmware, to configure the kernel driver.
>> This method was vetoed during the upstreaming process, so a fixed value of 32
>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>> the correct value.
>>
>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>> a 64-byte cache line. Document the new string in the binding, and use it on
>> the appropriate platforms.
>>
>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>> declaration for the device node, but it doubles as an indication to the
>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>> that chooses the correct value. As such it would help if the DT patches are
>> not merged before the driver patch.
>>
>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>> v2: Replaced ARM-specific logic used to determine cache line size with
>>     a new compatible string for BCM2836 and BCM2837.
>>
>> Phil Elwell (4):
>>   staging/vc04_services: Use correct cache line size
>>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>   ARM: dts: bcm283x: Correct vchiq compatible string
>>   ARM: dts: bcm283x: Correct mailbox register sizes
> 
> since my pull requests are out, would it be okay to apply patch #1 for
> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
> these patches)?

Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.

Phil

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

[Florian Fainelli]

On 09/17/2018 04:47 AM, Phil Elwell wrote:
> Hi Stefan,
> 
> On 17/09/2018 12:39, Stefan Wahren wrote:
>> Hi Phil,
>>
>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>>> line size. Using an incorrect value can lead to data corruption, but having the
>>> two sides using different values is usually worse.
>>>
>>> In the absence of an obvious convenient run-time method to determine the
>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>>> Device Tree property, written by the firmware, to configure the kernel driver.
>>> This method was vetoed during the upstreaming process, so a fixed value of 32
>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>>> the correct value.
>>>
>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>>> a 64-byte cache line. Document the new string in the binding, and use it on
>>> the appropriate platforms.
>>>
>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>>> declaration for the device node, but it doubles as an indication to the
>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>>> that chooses the correct value. As such it would help if the DT patches are
>>> not merged before the driver patch.
>>>
>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>>> v2: Replaced ARM-specific logic used to determine cache line size with
>>>     a new compatible string for BCM2836 and BCM2837.
>>>
>>> Phil Elwell (4):
>>>   staging/vc04_services: Use correct cache line size
>>>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>>   ARM: dts: bcm283x: Correct vchiq compatible string
>>>   ARM: dts: bcm283x: Correct mailbox register sizes
>>
>> since my pull requests are out, would it be okay to apply patch #1 for
>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
>> these patches)?
> 
> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.

Humm, did you mean you would like not to be delayed? In any case Stefan,
you can send an additional pull request, and I will merge it and send a
second pull request towards ARM SoC maintainers, that's not a problem.
-- 
Florian

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Florian Fainelli]

On 09/17/2018 04:47 AM, Phil Elwell wrote:
> Hi Stefan,
> 
> On 17/09/2018 12:39, Stefan Wahren wrote:
>> Hi Phil,
>>
>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>>> line size. Using an incorrect value can lead to data corruption, but having the
>>> two sides using different values is usually worse.
>>>
>>> In the absence of an obvious convenient run-time method to determine the
>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>>> Device Tree property, written by the firmware, to configure the kernel driver.
>>> This method was vetoed during the upstreaming process, so a fixed value of 32
>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>>> the correct value.
>>>
>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>>> a 64-byte cache line. Document the new string in the binding, and use it on
>>> the appropriate platforms.
>>>
>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>>> declaration for the device node, but it doubles as an indication to the
>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>>> that chooses the correct value. As such it would help if the DT patches are
>>> not merged before the driver patch.
>>>
>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>>> v2: Replaced ARM-specific logic used to determine cache line size with
>>>     a new compatible string for BCM2836 and BCM2837.
>>>
>>> Phil Elwell (4):
>>>   staging/vc04_services: Use correct cache line size
>>>   dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>>   ARM: dts: bcm283x: Correct vchiq compatible string
>>>   ARM: dts: bcm283x: Correct mailbox register sizes
>>
>> since my pull requests are out, would it be okay to apply patch #1 for
>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
>> these patches)?
> 
> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.

Humm, did you mean you would like not to be delayed? In any case Stefan,
you can send an additional pull request, and I will merge it and send a
second pull request towards ARM SoC maintainers, that's not a problem.
-- 
Florian

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

On 17/09/2018 18:51, Florian Fainelli wrote:
> On 09/17/2018 04:47 AM, Phil Elwell wrote:
>> Hi Stefan,
>>
>> On 17/09/2018 12:39, Stefan Wahren wrote:
>>> Hi Phil,
>>>
>>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>>>> line size. Using an incorrect value can lead to data corruption, but having the
>>>> two sides using different values is usually worse.
>>>>
>>>> In the absence of an obvious convenient run-time method to determine the
>>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>>>> Device Tree property, written by the firmware, to configure the kernel driver.
>>>> This method was vetoed during the upstreaming process, so a fixed value of 32
>>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>>>> the correct value.
>>>>
>>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>>>> a 64-byte cache line. Document the new string in the binding, and use it on
>>>> the appropriate platforms.
>>>>
>>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>>>> declaration for the device node, but it doubles as an indication to the
>>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>>>> that chooses the correct value. As such it would help if the DT patches are
>>>> not merged before the driver patch.
>>>>
>>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>>>> v2: Replaced ARM-specific logic used to determine cache line size with
>>>>      a new compatible string for BCM2836 and BCM2837.
>>>>
>>>> Phil Elwell (4):
>>>>    staging/vc04_services: Use correct cache line size
>>>>    dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>>>    ARM: dts: bcm283x: Correct vchiq compatible string
>>>>    ARM: dts: bcm283x: Correct mailbox register sizes
>>>
>>> since my pull requests are out, would it be okay to apply patch #1 for
>>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
>>> these patches)?
>>
>> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.
> 
> Humm, did you mean you would like not to be delayed? In any case Stefan,
> you can send an additional pull request, and I will merge it and send a
> second pull request towards ARM SoC maintainers, that's not a problem.

No, I meant what I wrote - I would prefer patch 1 to be merged before patch 4 (or at least
in the same release) to avoid the need for another firmware change, hence delaying patch
4 is good. It makes sense for the other commits to be merged in that order, but the
normal compatible-string fallback mechanism means there is no hard dependency there.

Phil

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Phil Elwell]

On 17/09/2018 18:51, Florian Fainelli wrote:
> On 09/17/2018 04:47 AM, Phil Elwell wrote:
>> Hi Stefan,
>>
>> On 17/09/2018 12:39, Stefan Wahren wrote:
>>> Hi Phil,
>>>
>>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
>>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
>>>> line size. Using an incorrect value can lead to data corruption, but having the
>>>> two sides using different values is usually worse.
>>>>
>>>> In the absence of an obvious convenient run-time method to determine the
>>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
>>>> Device Tree property, written by the firmware, to configure the kernel driver.
>>>> This method was vetoed during the upstreaming process, so a fixed value of 32
>>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
>>>> the correct value.
>>>>
>>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
>>>> a 64-byte cache line. Document the new string in the binding, and use it on
>>>> the appropriate platforms.
>>>>
>>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
>>>> declaration for the device node, but it doubles as an indication to the
>>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
>>>> that chooses the correct value. As such it would help if the DT patches are
>>>> not merged before the driver patch.
>>>>
>>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
>>>> v2: Replaced ARM-specific logic used to determine cache line size with
>>>>      a new compatible string for BCM2836 and BCM2837.
>>>>
>>>> Phil Elwell (4):
>>>>    staging/vc04_services: Use correct cache line size
>>>>    dt-bindings: soc: Document "brcm,bcm2836-vchiq"
>>>>    ARM: dts: bcm283x: Correct vchiq compatible string
>>>>    ARM: dts: bcm283x: Correct mailbox register sizes
>>>
>>> since my pull requests are out, would it be okay to apply patch #1 for
>>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
>>> these patches)?
>>
>> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.
> 
> Humm, did you mean you would like not to be delayed? In any case Stefan,
> you can send an additional pull request, and I will merge it and send a
> second pull request towards ARM SoC maintainers, that's not a problem.

No, I meant what I wrote - I would prefer patch 1 to be merged before patch 4 (or at least
in the same release) to avoid the need for another firmware change, hence delaying patch
4 is good. It makes sense for the other commits to be merged in that order, but the
normal compatible-string fallback mechanism means there is no hard dependency there.

Phil

Re: [PATCH v3 1/4] staging/vc04_services: Use correct cache line size

[Stefan Wahren]

> Phil Elwell <phil@raspberrypi.org> hat am 17. September 2018 um 10:22 geschrieben:
> 
> 
> Use the compatible string in the DTB to select the correct cache line
> size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837.
> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Tested-by: Stefan Wahren <stefan.wahren@i2se.com>

[PATCH v3 1/4] staging/vc04_services: Use correct cache line size

[Stefan Wahren]

> Phil Elwell <phil@raspberrypi.org> hat am 17. September 2018 um 10:22 geschrieben:
> 
> 
> Use the compatible string in the DTB to select the correct cache line
> size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837.
> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Tested-by: Stefan Wahren <stefan.wahren@i2se.com>

Re: [PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

[Rob Herring]

On Mon, 17 Sep 2018 09:22:22 +0100, Phil Elwell wrote:
> "brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure
> correct operation.
> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

[PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

[Rob Herring]

On Mon, 17 Sep 2018 09:22:22 +0100, Phil Elwell wrote:
> "brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure
> correct operation.
> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

[Stefan Wahren]

> Phil Elwell <phil@raspberrypi.org> hat am 17. September 2018 um 20:01 geschrieben:
> 
> 
> On 17/09/2018 18:51, Florian Fainelli wrote:
> > On 09/17/2018 04:47 AM, Phil Elwell wrote:
> >> Hi Stefan,
> >>
> >> On 17/09/2018 12:39, Stefan Wahren wrote:
> >>> Hi Phil,
> >>>
> >>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
> >>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
> >>>> line size. Using an incorrect value can lead to data corruption, but having the
> >>>> two sides using different values is usually worse.
> >>>>
> >>>> In the absence of an obvious convenient run-time method to determine the
> >>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
> >>>> Device Tree property, written by the firmware, to configure the kernel driver.
> >>>> This method was vetoed during the upstreaming process, so a fixed value of 32
> >>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
> >>>> the correct value.
> >>>>
> >>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
> >>>> a 64-byte cache line. Document the new string in the binding, and use it on
> >>>> the appropriate platforms.
> >>>>
> >>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
> >>>> declaration for the device node, but it doubles as an indication to the
> >>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
> >>>> that chooses the correct value. As such it would help if the DT patches are
> >>>> not merged before the driver patch.
> >>>>
> >>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
> >>>> v2: Replaced ARM-specific logic used to determine cache line size with
> >>>>      a new compatible string for BCM2836 and BCM2837.
> >>>>
> >>>> Phil Elwell (4):
> >>>>    staging/vc04_services: Use correct cache line size
> >>>>    dt-bindings: soc: Document "brcm,bcm2836-vchiq"
> >>>>    ARM: dts: bcm283x: Correct vchiq compatible string
> >>>>    ARM: dts: bcm283x: Correct mailbox register sizes
> >>>
> >>> since my pull requests are out, would it be okay to apply patch #1 for
> >>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
> >>> these patches)?
> >>
> >> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.
> > 
> > Humm, did you mean you would like not to be delayed? In any case Stefan,
> > you can send an additional pull request, and I will merge it and send a
> > second pull request towards ARM SoC maintainers, that's not a problem.
> 
> No, I meant what I wrote - I would prefer patch 1 to be merged before patch 4 (or at least
> in the same release) to avoid the need for another firmware change, hence delaying patch
> 4 is good. It makes sense for the other commits to be merged in that order, but the
> normal compatible-string fallback mechanism means there is no hard dependency there.
> 
> Phil

Patches #2 - #4 applied to bcm2835-dt-next

Thanks

[PATCH v3 0/4] Improve VCHIQ cache line size handling

[Stefan Wahren]

> Phil Elwell <phil@raspberrypi.org> hat am 17. September 2018 um 20:01 geschrieben:
> 
> 
> On 17/09/2018 18:51, Florian Fainelli wrote:
> > On 09/17/2018 04:47 AM, Phil Elwell wrote:
> >> Hi Stefan,
> >>
> >> On 17/09/2018 12:39, Stefan Wahren wrote:
> >>> Hi Phil,
> >>>
> >>> Am 17.09.2018 um 10:22 schrieb Phil Elwell:
> >>>> Both sides of the VCHIQ communications mechanism need to agree on the cache
> >>>> line size. Using an incorrect value can lead to data corruption, but having the
> >>>> two sides using different values is usually worse.
> >>>>
> >>>> In the absence of an obvious convenient run-time method to determine the
> >>>> correct value in the ARCH=arm world, the downstream Raspberry Pi trees used a
> >>>> Device Tree property, written by the firmware, to configure the kernel driver.
> >>>> This method was vetoed during the upstreaming process, so a fixed value of 32
> >>>> was used instead, and some corruptions ensued. This is take 2 at arriving at
> >>>> the correct value.
> >>>>
> >>>> Add a new compatible string - "brcm,bcm2836-vchiq" - to indicate an SoC with
> >>>> a 64-byte cache line. Document the new string in the binding, and use it on
> >>>> the appropriate platforms.
> >>>>
> >>>> The final patch is a (seemingly cosmetic) correction of the Device Tree "reg"
> >>>> declaration for the device node, but it doubles as an indication to the
> >>>> Raspberry Pi firmware that the kernel driver is running a recent kernel driver
> >>>> that chooses the correct value. As such it would help if the DT patches are
> >>>> not merged before the driver patch.
> >>>>
> >>>> v3: Builds without errors, tested on multiple Raspberry Pi models.
> >>>> v2: Replaced ARM-specific logic used to determine cache line size with
> >>>>      a new compatible string for BCM2836 and BCM2837.
> >>>>
> >>>> Phil Elwell (4):
> >>>>    staging/vc04_services: Use correct cache line size
> >>>>    dt-bindings: soc: Document "brcm,bcm2836-vchiq"
> >>>>    ARM: dts: bcm283x: Correct vchiq compatible string
> >>>>    ARM: dts: bcm283x: Correct mailbox register sizes
> >>>
> >>> since my pull requests are out, would it be okay to apply patch #1 for
> >>> 4.20 and the DT stuff for 4.21 (with the assumption Rob is okay with
> >>> these patches)?
> >>
> >> Patch 4 is the only one I'd like to be delayed, but delaying 2-4 is fine with me.
> > 
> > Humm, did you mean you would like not to be delayed? In any case Stefan,
> > you can send an additional pull request, and I will merge it and send a
> > second pull request towards ARM SoC maintainers, that's not a problem.
> 
> No, I meant what I wrote - I would prefer patch 1 to be merged before patch 4 (or at least
> in the same release) to avoid the need for another firmware change, hence delaying patch
> 4 is good. It makes sense for the other commits to be merged in that order, but the
> normal compatible-string fallback mechanism means there is no hard dependency there.
> 
> Phil

Patches #2 - #4 applied to bcm2835-dt-next

Thanks