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

Reply via email to