devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Elwell <phil@raspberrypi.org>
To: Rob Herring <robh+dt@kernel.org>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Phil Elwell <phil@raspberrypi.org>,
	devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-arm-kernel@lists.infradead.org,
	bcm-kernel-feedback-list@broadcom.com,
	devel@driverdev.osuosl.org
Subject: [PATCH v3 0/4] Improve VCHIQ cache line size handling
Date: Mon, 17 Sep 2018 09:22:20 +0100	[thread overview]
Message-ID: <1537172544-104852-1-git-send-email-phil@raspberrypi.org> (raw)

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

             reply	other threads:[~2018-09-17  8:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17  8:22 Phil Elwell [this message]
2018-09-17  8:22 ` [PATCH v3 1/4] staging/vc04_services: Use correct cache line size Phil Elwell
2018-09-23 15:24   ` Stefan Wahren
2018-09-17  8:22 ` [PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq" Phil Elwell
2018-09-26 22:37   ` Rob Herring
2018-09-17  8:22 ` [PATCH v3 3/4] ARM: dts: bcm283x: Correct vchiq compatible string Phil Elwell
2018-09-17  8:22 ` [PATCH v3 4/4] ARM: dts: bcm283x: Correct mailbox register sizes Phil Elwell
2018-09-17 11:39 ` [PATCH v3 0/4] Improve VCHIQ cache line size handling Stefan Wahren
2018-09-17 11:47   ` Phil Elwell
2018-09-17 17:51     ` Florian Fainelli
2018-09-17 18:01       ` Phil Elwell
2018-11-06 18:20         ` Stefan Wahren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1537172544-104852-1-git-send-email-phil@raspberrypi.org \
    --to=phil@raspberrypi.org \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=stefan.wahren@i2se.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).