diff mbox

[2/5] staging: vc04_services: Remove cache-line-size property.

Message ID 20180305202806.21219-3-eric@anholt.net (mailing list archive)
State New, archived
Headers show

Commit Message

Eric Anholt March 5, 2018, 8:28 p.m. UTC
This was just a way for the DT-passed value to get out of sync with
what Linux has configured the ARM for.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 .../interface/vchiq_arm/vchiq_2835_arm.c           | 25 +++++++---------------
 .../interface/vchiq_arm/vchiq_pagelist.h           |  1 -
 2 files changed, 8 insertions(+), 18 deletions(-)

Comments

Stefan Wahren March 6, 2018, 10:30 a.m. UTC | #1
Hi Eric,


Am 05.03.2018 um 21:28 schrieb Eric Anholt:
> This was just a way for the DT-passed value to get out of sync with
> what Linux has configured the ARM for.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>   .../interface/vchiq_arm/vchiq_2835_arm.c           | 25 +++++++---------------
>   .../interface/vchiq_arm/vchiq_pagelist.h           |  1 -
>   2 files changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> index b59ef14890aa..e0e01c812036 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> @@ -77,7 +77,6 @@ struct vchiq_pagelist_info {
>   };
>   
>   static void __iomem *g_regs;
> -static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
>   static unsigned int g_fragments_size;
>   static char *g_fragments_base;
>   static char *g_free_fragments;
> @@ -117,15 +116,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
>   	if (err < 0)
>   		return err;
>   
> -	err = of_property_read_u32(dev->of_node, "cache-line-size",
> -				   &g_cache_line_size);
> -
> -	if (err) {
> -		dev_err(dev, "Missing cache-line-size property\n");
> -		return -ENODEV;
> -	}
> -
> -	g_fragments_size = 2 * g_cache_line_size;
> +	g_fragments_size = 2 * cache_line_size();
>   
>   	/* Allocate space for the channels in coherent memory */
>   	slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
> @@ -548,9 +539,9 @@ create_pagelist(char __user *buf, size_t count, unsigned short type)
>   
>   	/* Partial cache lines (fragments) require special measures */
>   	if ((type == PAGELIST_READ) &&
> -		((pagelist->offset & (g_cache_line_size - 1)) ||
> +		((pagelist->offset & (cache_line_size() - 1)) ||
>   		((pagelist->offset + pagelist->length) &
> -		(g_cache_line_size - 1)))) {
> +		 (cache_line_size() - 1)))) {
>   		char *fragments;
>   
>   		if (down_interruptible(&g_free_fragments_sema) != 0) {
> @@ -598,10 +589,10 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
>   			g_fragments_size;
>   		int head_bytes, tail_bytes;
>   
> -		head_bytes = (g_cache_line_size - pagelist->offset) &
> -			(g_cache_line_size - 1);
> +		head_bytes = (cache_line_size() - pagelist->offset) &
> +			(cache_line_size() - 1);
>   		tail_bytes = (pagelist->offset + actual) &
> -			(g_cache_line_size - 1);
> +			(cache_line_size() - 1);

should it be so easy? Back in 2016 we said that cache_line_size() won't 
work. I always thought that we need the cache line size of L2 not of the 
L1 one.

Did you already test the behavior for these combinations?
BCM2835 ARM32, expected cache line size = 32
BCM2836 ARM32, expected cache line size = 64
BCM2837 ARM32, expected cache line size = 64
BCM2837 ARM64, expected cache line size = 64

Regards
Stefan

>   
>   		if ((actual >= 0) && (head_bytes != 0)) {
>   			if (head_bytes > actual)
> @@ -617,8 +608,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
>   			(tail_bytes != 0)) {
>   			memcpy((char *)kmap(pages[num_pages - 1]) +
>   				((pagelist->offset + actual) &
> -				(PAGE_SIZE - 1) & ~(g_cache_line_size - 1)),
> -				fragments + g_cache_line_size,
> +				(PAGE_SIZE - 1) & ~(cache_line_size() - 1)),
> +				fragments + cache_line_size(),
>   				tail_bytes);
>   			kunmap(pages[num_pages - 1]);
>   		}
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
> index a6c5f7cc78f0..bec411061554 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
> @@ -34,7 +34,6 @@
>   #ifndef VCHIQ_PAGELIST_H
>   #define VCHIQ_PAGELIST_H
>   
> -#define CACHE_LINE_SIZE 32
>   #define PAGELIST_WRITE 0
>   #define PAGELIST_READ 1
>   #define PAGELIST_READ_WITH_FRAGMENTS 2
Eric Anholt March 6, 2018, 7:02 p.m. UTC | #2
Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Eric,
>
>
> Am 05.03.2018 um 21:28 schrieb Eric Anholt:
>> This was just a way for the DT-passed value to get out of sync with
>> what Linux has configured the ARM for.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> ---
>>   .../interface/vchiq_arm/vchiq_2835_arm.c           | 25 +++++++---------------
>>   .../interface/vchiq_arm/vchiq_pagelist.h           |  1 -
>>   2 files changed, 8 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>> index b59ef14890aa..e0e01c812036 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>> @@ -77,7 +77,6 @@ struct vchiq_pagelist_info {
>>   };
>>   
>>   static void __iomem *g_regs;
>> -static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
>>   static unsigned int g_fragments_size;
>>   static char *g_fragments_base;
>>   static char *g_free_fragments;
>> @@ -117,15 +116,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
>>   	if (err < 0)
>>   		return err;
>>   
>> -	err = of_property_read_u32(dev->of_node, "cache-line-size",
>> -				   &g_cache_line_size);
>> -
>> -	if (err) {
>> -		dev_err(dev, "Missing cache-line-size property\n");
>> -		return -ENODEV;
>> -	}
>> -
>> -	g_fragments_size = 2 * g_cache_line_size;
>> +	g_fragments_size = 2 * cache_line_size();
>>   
>>   	/* Allocate space for the channels in coherent memory */
>>   	slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
>> @@ -548,9 +539,9 @@ create_pagelist(char __user *buf, size_t count, unsigned short type)
>>   
>>   	/* Partial cache lines (fragments) require special measures */
>>   	if ((type == PAGELIST_READ) &&
>> -		((pagelist->offset & (g_cache_line_size - 1)) ||
>> +		((pagelist->offset & (cache_line_size() - 1)) ||
>>   		((pagelist->offset + pagelist->length) &
>> -		(g_cache_line_size - 1)))) {
>> +		 (cache_line_size() - 1)))) {
>>   		char *fragments;
>>   
>>   		if (down_interruptible(&g_free_fragments_sema) != 0) {
>> @@ -598,10 +589,10 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
>>   			g_fragments_size;
>>   		int head_bytes, tail_bytes;
>>   
>> -		head_bytes = (g_cache_line_size - pagelist->offset) &
>> -			(g_cache_line_size - 1);
>> +		head_bytes = (cache_line_size() - pagelist->offset) &
>> +			(cache_line_size() - 1);
>>   		tail_bytes = (pagelist->offset + actual) &
>> -			(g_cache_line_size - 1);
>> +			(cache_line_size() - 1);
>
> should it be so easy? Back in 2016 we said that cache_line_size() won't 
> work. I always thought that we need the cache line size of L2 not of the 
> L1 one.
>
> Did you already test the behavior for these combinations?
> BCM2835 ARM32, expected cache line size = 32
> BCM2836 ARM32, expected cache line size = 64
> BCM2837 ARM32, expected cache line size = 64
> BCM2837 ARM64, expected cache line size = 64

I didn't explicitly test, but was going by:

config ARM_L1_CACHE_SHIFT_6
	bool
	default y if CPU_V7
	help
	  Setting ARM L1 cache line size to 64 Bytes.

config ARM_L1_CACHE_SHIFT_7
	bool
	help
	  Setting ARM L1 cache line size to 128 Bytes.

config ARM_L1_CACHE_SHIFT
	int
	default 7 if ARM_L1_CACHE_SHIFT_7
	default 6 if ARM_L1_CACHE_SHIFT_6
	default 5

and only L1_CACHE_SHIFT_7 gets selected by UNIPHIER and neither one is
accessible by menus.

I think you're technically correct that it's the size of L2 that matters
(or, specifically, the hardcoded value that the firmware is using on its
side for the fragments list handling.  It overrides a cache-line-size DT
property with that number if present).  However, I think L1==L2 cache
line size this should be a safe assumption for us.

Phil, any opinion?
Phil Elwell March 7, 2018, 8:02 a.m. UTC | #3
Hi Eric,

On 06/03/2018 19:02, Eric Anholt wrote:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
> 
>> Hi Eric,
>>
>>
>> Am 05.03.2018 um 21:28 schrieb Eric Anholt:
>>> This was just a way for the DT-passed value to get out of sync with
>>> what Linux has configured the ARM for.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>> ---
>>>    .../interface/vchiq_arm/vchiq_2835_arm.c           | 25 +++++++---------------
>>>    .../interface/vchiq_arm/vchiq_pagelist.h           |  1 -
>>>    2 files changed, 8 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>>> index b59ef14890aa..e0e01c812036 100644
>>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
>>> @@ -77,7 +77,6 @@ struct vchiq_pagelist_info {
>>>    };
>>>    
>>>    static void __iomem *g_regs;
>>> -static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
>>>    static unsigned int g_fragments_size;
>>>    static char *g_fragments_base;
>>>    static char *g_free_fragments;
>>> @@ -117,15 +116,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
>>>    	if (err < 0)
>>>    		return err;
>>>    
>>> -	err = of_property_read_u32(dev->of_node, "cache-line-size",
>>> -				   &g_cache_line_size);
>>> -
>>> -	if (err) {
>>> -		dev_err(dev, "Missing cache-line-size property\n");
>>> -		return -ENODEV;
>>> -	}
>>> -
>>> -	g_fragments_size = 2 * g_cache_line_size;
>>> +	g_fragments_size = 2 * cache_line_size();
>>>    
>>>    	/* Allocate space for the channels in coherent memory */
>>>    	slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
>>> @@ -548,9 +539,9 @@ create_pagelist(char __user *buf, size_t count, unsigned short type)
>>>    
>>>    	/* Partial cache lines (fragments) require special measures */
>>>    	if ((type == PAGELIST_READ) &&
>>> -		((pagelist->offset & (g_cache_line_size - 1)) ||
>>> +		((pagelist->offset & (cache_line_size() - 1)) ||
>>>    		((pagelist->offset + pagelist->length) &
>>> -		(g_cache_line_size - 1)))) {
>>> +		 (cache_line_size() - 1)))) {
>>>    		char *fragments;
>>>    
>>>    		if (down_interruptible(&g_free_fragments_sema) != 0) {
>>> @@ -598,10 +589,10 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
>>>    			g_fragments_size;
>>>    		int head_bytes, tail_bytes;
>>>    
>>> -		head_bytes = (g_cache_line_size - pagelist->offset) &
>>> -			(g_cache_line_size - 1);
>>> +		head_bytes = (cache_line_size() - pagelist->offset) &
>>> +			(cache_line_size() - 1);
>>>    		tail_bytes = (pagelist->offset + actual) &
>>> -			(g_cache_line_size - 1);
>>> +			(cache_line_size() - 1);
>>
>> should it be so easy? Back in 2016 we said that cache_line_size() won't
>> work. I always thought that we need the cache line size of L2 not of the
>> L1 one.
>>
>> Did you already test the behavior for these combinations?
>> BCM2835 ARM32, expected cache line size = 32
>> BCM2836 ARM32, expected cache line size = 64
>> BCM2837 ARM32, expected cache line size = 64
>> BCM2837 ARM64, expected cache line size = 64
> 
> I didn't explicitly test, but was going by:
> 
> config ARM_L1_CACHE_SHIFT_6
> 	bool
> 	default y if CPU_V7
> 	help
> 	  Setting ARM L1 cache line size to 64 Bytes.
> 
> config ARM_L1_CACHE_SHIFT_7
> 	bool
> 	help
> 	  Setting ARM L1 cache line size to 128 Bytes.
> 
> config ARM_L1_CACHE_SHIFT
> 	int
> 	default 7 if ARM_L1_CACHE_SHIFT_7
> 	default 6 if ARM_L1_CACHE_SHIFT_6
> 	default 5
> 
> and only L1_CACHE_SHIFT_7 gets selected by UNIPHIER and neither one is
> accessible by menus.
> 
> I think you're technically correct that it's the size of L2 that matters
> (or, specifically, the hardcoded value that the firmware is using on its
> side for the fragments list handling.  It overrides a cache-line-size DT
> property with that number if present).  However, I think L1==L2 cache
> line size this should be a safe assumption for us.
> 
> Phil, any opinion?

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.

Phil
Stefan Wahren March 7, 2018, 12:10 p.m. UTC | #4
Hi Phil,

> Phil Elwell <phil@raspberrypi.org> hat am 7. März 2018 um 09:02 geschrieben:
> 
> 
> Hi Eric,
> 
> On 06/03/2018 19:02, Eric Anholt wrote:
> > Stefan Wahren <stefan.wahren@i2se.com> writes:
> > 
> >> Hi Eric,
> >>
> >>
> >> Am 05.03.2018 um 21:28 schrieb Eric Anholt:
> >>> This was just a way for the DT-passed value to get out of sync with
> >>> what Linux has configured the ARM for.
> >>>
> >>> Signed-off-by: Eric Anholt <eric@anholt.net>
> >>> ---
> >>>    .../interface/vchiq_arm/vchiq_2835_arm.c           | 25 +++++++---------------
> >>>    .../interface/vchiq_arm/vchiq_pagelist.h           |  1 -
> >>>    2 files changed, 8 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> >>> index b59ef14890aa..e0e01c812036 100644
> >>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> >>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> >>> @@ -77,7 +77,6 @@ struct vchiq_pagelist_info {
> >>>    };
> >>>    
> >>>    static void __iomem *g_regs;
> >>> -static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
> >>>    static unsigned int g_fragments_size;
> >>>    static char *g_fragments_base;
> >>>    static char *g_free_fragments;
> >>> @@ -117,15 +116,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
> >>>    	if (err < 0)
> >>>    		return err;
> >>>    
> >>> -	err = of_property_read_u32(dev->of_node, "cache-line-size",
> >>> -				   &g_cache_line_size);
> >>> -
> >>> -	if (err) {
> >>> -		dev_err(dev, "Missing cache-line-size property\n");
> >>> -		return -ENODEV;
> >>> -	}
> >>> -
> >>> -	g_fragments_size = 2 * g_cache_line_size;
> >>> +	g_fragments_size = 2 * cache_line_size();
> >>>    
> >>>    	/* Allocate space for the channels in coherent memory */
> >>>    	slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
> >>> @@ -548,9 +539,9 @@ create_pagelist(char __user *buf, size_t count, unsigned short type)
> >>>    
> >>>    	/* Partial cache lines (fragments) require special measures */
> >>>    	if ((type == PAGELIST_READ) &&
> >>> -		((pagelist->offset & (g_cache_line_size - 1)) ||
> >>> +		((pagelist->offset & (cache_line_size() - 1)) ||
> >>>    		((pagelist->offset + pagelist->length) &
> >>> -		(g_cache_line_size - 1)))) {
> >>> +		 (cache_line_size() - 1)))) {
> >>>    		char *fragments;
> >>>    
> >>>    		if (down_interruptible(&g_free_fragments_sema) != 0) {
> >>> @@ -598,10 +589,10 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
> >>>    			g_fragments_size;
> >>>    		int head_bytes, tail_bytes;
> >>>    
> >>> -		head_bytes = (g_cache_line_size - pagelist->offset) &
> >>> -			(g_cache_line_size - 1);
> >>> +		head_bytes = (cache_line_size() - pagelist->offset) &
> >>> +			(cache_line_size() - 1);
> >>>    		tail_bytes = (pagelist->offset + actual) &
> >>> -			(g_cache_line_size - 1);
> >>> +			(cache_line_size() - 1);
> >>
> >> should it be so easy? Back in 2016 we said that cache_line_size() won't
> >> work. I always thought that we need the cache line size of L2 not of the
> >> L1 one.
> >>
> >> Did you already test the behavior for these combinations?
> >> BCM2835 ARM32, expected cache line size = 32
> >> BCM2836 ARM32, expected cache line size = 64
> >> BCM2837 ARM32, expected cache line size = 64
> >> BCM2837 ARM64, expected cache line size = 64
> > 
> > I didn't explicitly test, but was going by:
> > 
> > config ARM_L1_CACHE_SHIFT_6
> > 	bool
> > 	default y if CPU_V7
> > 	help
> > 	  Setting ARM L1 cache line size to 64 Bytes.
> > 
> > config ARM_L1_CACHE_SHIFT_7
> > 	bool
> > 	help
> > 	  Setting ARM L1 cache line size to 128 Bytes.
> > 
> > config ARM_L1_CACHE_SHIFT
> > 	int
> > 	default 7 if ARM_L1_CACHE_SHIFT_7
> > 	default 6 if ARM_L1_CACHE_SHIFT_6
> > 	default 5
> > 
> > and only L1_CACHE_SHIFT_7 gets selected by UNIPHIER and neither one is
> > accessible by menus.
> > 
> > I think you're technically correct that it's the size of L2 that matters
> > (or, specifically, the hardcoded value that the firmware is using on its
> > side for the fragments list handling.  It overrides a cache-line-size DT
> > property with that number if present).  However, I think L1==L2 cache
> > line size this should be a safe assumption for us.
> > 
> > Phil, any opinion?
> 
> 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"?

Btw it would be nice to get fixed the corruption on ARM64 [1].

Stefan

[1] - https://github.com/lategoodbye/rpi-zero/issues/23

> 
> Phil
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Phil Elwell March 7, 2018, 12:39 p.m. UTC | #5
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.

> Btw it would be nice to get fixed the corruption on ARM64 [1].

This is almost certainly due to the logic described above.

> 
> Stefan
> 
> [1] - https://github.com/lategoodbye/rpi-zero/issues/23
> 
>>
>> Phil
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Eric Anholt March 7, 2018, 5:51 p.m. UTC | #6
Phil Elwell <phil@raspberrypi.org> 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.
diff mbox

Patch

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index b59ef14890aa..e0e01c812036 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -77,7 +77,6 @@  struct vchiq_pagelist_info {
 };
 
 static void __iomem *g_regs;
-static unsigned int g_cache_line_size = sizeof(CACHE_LINE_SIZE);
 static unsigned int g_fragments_size;
 static char *g_fragments_base;
 static char *g_free_fragments;
@@ -117,15 +116,7 @@  int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 	if (err < 0)
 		return err;
 
-	err = of_property_read_u32(dev->of_node, "cache-line-size",
-				   &g_cache_line_size);
-
-	if (err) {
-		dev_err(dev, "Missing cache-line-size property\n");
-		return -ENODEV;
-	}
-
-	g_fragments_size = 2 * g_cache_line_size;
+	g_fragments_size = 2 * cache_line_size();
 
 	/* Allocate space for the channels in coherent memory */
 	slot_mem_size = PAGE_ALIGN(TOTAL_SLOTS * VCHIQ_SLOT_SIZE);
@@ -548,9 +539,9 @@  create_pagelist(char __user *buf, size_t count, unsigned short type)
 
 	/* Partial cache lines (fragments) require special measures */
 	if ((type == PAGELIST_READ) &&
-		((pagelist->offset & (g_cache_line_size - 1)) ||
+		((pagelist->offset & (cache_line_size() - 1)) ||
 		((pagelist->offset + pagelist->length) &
-		(g_cache_line_size - 1)))) {
+		 (cache_line_size() - 1)))) {
 		char *fragments;
 
 		if (down_interruptible(&g_free_fragments_sema) != 0) {
@@ -598,10 +589,10 @@  free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 			g_fragments_size;
 		int head_bytes, tail_bytes;
 
-		head_bytes = (g_cache_line_size - pagelist->offset) &
-			(g_cache_line_size - 1);
+		head_bytes = (cache_line_size() - pagelist->offset) &
+			(cache_line_size() - 1);
 		tail_bytes = (pagelist->offset + actual) &
-			(g_cache_line_size - 1);
+			(cache_line_size() - 1);
 
 		if ((actual >= 0) && (head_bytes != 0)) {
 			if (head_bytes > actual)
@@ -617,8 +608,8 @@  free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 			(tail_bytes != 0)) {
 			memcpy((char *)kmap(pages[num_pages - 1]) +
 				((pagelist->offset + actual) &
-				(PAGE_SIZE - 1) & ~(g_cache_line_size - 1)),
-				fragments + g_cache_line_size,
+				(PAGE_SIZE - 1) & ~(cache_line_size() - 1)),
+				fragments + cache_line_size(),
 				tail_bytes);
 			kunmap(pages[num_pages - 1]);
 		}
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
index a6c5f7cc78f0..bec411061554 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_pagelist.h
@@ -34,7 +34,6 @@ 
 #ifndef VCHIQ_PAGELIST_H
 #define VCHIQ_PAGELIST_H
 
-#define CACHE_LINE_SIZE 32
 #define PAGELIST_WRITE 0
 #define PAGELIST_READ 1
 #define PAGELIST_READ_WITH_FRAGMENTS 2