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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux