> Phil Elwell <phil@xxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
