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

Stefan Wahren stefan.wahren at i2se.com
Tue Nov 6 18:20:45 UTC 2018


> Phil Elwell <phil at 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


More information about the devel mailing list