All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Phil Elwell <phil@raspberrypi.org>
Cc: linux-kernel@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/5] staging: vc04_services: Remove cache-line-size property.
Date: Tue, 06 Mar 2018 11:02:04 -0800	[thread overview]
Message-ID: <87muzl9ger.fsf@anholt.net> (raw)
In-Reply-To: <a8f369f5-691c-c05f-4c7c-2eadcf4c48c8@i2se.com>

[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: eric@anholt.net (Eric Anholt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] staging: vc04_services: Remove cache-line-size property.
Date: Tue, 06 Mar 2018 11:02:04 -0800	[thread overview]
Message-ID: <87muzl9ger.fsf@anholt.net> (raw)
In-Reply-To: <a8f369f5-691c-c05f-4c7c-2eadcf4c48c8@i2se.com>

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180306/cb86fa60/attachment.sig>

  reply	other threads:[~2018-03-06 19:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 20:28 [PATCH 0/5] VCHI DT bindings Eric Anholt
2018-03-05 20:28 ` Eric Anholt
2018-03-05 20:28 ` [PATCH 1/5] staging: vc04_services: Remove dead FRAGMENTS_T Eric Anholt
2018-03-05 20:28   ` Eric Anholt
2018-03-05 20:28 ` [PATCH 2/5] staging: vc04_services: Remove cache-line-size property Eric Anholt
2018-03-05 20:28   ` Eric Anholt
2018-03-06 10:30   ` Stefan Wahren
2018-03-06 10:30     ` Stefan Wahren
2018-03-06 10:30     ` Stefan Wahren
2018-03-06 19:02     ` Eric Anholt [this message]
2018-03-06 19:02       ` Eric Anholt
2018-03-07  8:02       ` Phil Elwell
2018-03-07  8:02         ` Phil Elwell
2018-03-07  8:02         ` Phil Elwell
2018-03-07 12:10         ` Stefan Wahren
2018-03-07 12:10           ` Stefan Wahren
2018-03-07 12:10           ` Stefan Wahren
2018-03-07 12:39           ` Phil Elwell
2018-03-07 12:39             ` Phil Elwell
2018-03-07 12:39             ` Phil Elwell
2018-03-07 17:51             ` Eric Anholt
2018-03-07 17:51               ` Eric Anholt
2018-03-05 20:28 ` [PATCH 3/5] dt-bindings: soc: Add a binding for the Broadcom VCHI services Eric Anholt
2018-03-05 20:28   ` Eric Anholt
2018-03-05 20:51   ` Rob Herring
2018-03-05 20:51     ` Rob Herring
2018-03-05 20:28 ` [PATCH 4/5] ARM: dts: bcm2835: Add VCHI node to the Raspberry Pi boards Eric Anholt
2018-03-05 20:28   ` Eric Anholt
2018-03-05 20:28   ` Eric Anholt
2018-03-05 20:28 ` [PATCH 5/5] staging: vc04_services: Mark the "DT bindings" job done Eric Anholt
2018-03-05 20:28   ` Eric Anholt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87muzl9ger.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=phil@raspberrypi.org \
    --cc=robh+dt@kernel.org \
    --cc=stefan.wahren@i2se.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.