Phil Elwell <phil@xxxxxxxxxxxxxxx> writes: > On 07/03/2018 12:10, Stefan Wahren wrote: >> Hi Phil, > > <snip> > >>> It is the L2 cache line size that matters, but as long as you end up with >>> the numbers Stefan mentioned - 32 on BCM2835, 64 on BCM2836 and BCM2837 - >>> I'm not too bothered how you get there. >> >> i think a kernel with bcm2835_defconfig on RPi 2 could be such a corncase. >> >> Am i right that the firmware doesn't rely on the existence of "cache-line-size"? > > Because of the way partial cache lines are handled it is more important that the > two sides agree than that the value is correct. As a result, the firmware treats > the absence of a "cache_line_size" DT parameter (that sets the "cache-line-size" > property) in the DTB as an indication that the kernel driver pre-dates the ability > to switch, and uses the old fixed value of 32 as a fallback. Otherwise it sets the > parameter and the internal value used by the VPU-side VCHIQ to the correct value. > > There are a number of ways to fix this, the easiest of which is to assume that the kernel > driver will either read the property or be able to work out the correct value, so > the VPU should always use the correct value regardless of the success of applying > the parameter/changing the property. Oh, interesting. So with my patch, we end up with a mismatch where VPU is treating things as 32, and the kernel is using 64. I wasn't seeing errors in vchiq_test in this state, which is a bit concerning. I'll go ahead and drop this patch and replace it with a comment in the code about this discussion.
Attachment:
signature.asc
Description: PGP signature
