[PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Florian Fainelli]

Some older machines such as the DECStation use a L1 data-cache shift of
2 (value of 4), add a Kconfig symbol for this value so they can express
this requirement.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
 arch/mips/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 03d0ed3..9ab4239 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1098,6 +1098,9 @@ config FW_SNIPROM
 config BOOT_ELF32
 	bool
 
+config MIPS_L1_CACHE_SHIFT_2
+	bool
+
 config MIPS_L1_CACHE_SHIFT_4
 	bool
 
@@ -1112,6 +1115,7 @@ config MIPS_L1_CACHE_SHIFT_7
 
 config MIPS_L1_CACHE_SHIFT
 	int
+	default "2" if MIPS_L1_CACHE_SHIFT_2
 	default "4" if MIPS_L1_CACHE_SHIFT_4
 	default "5" if MIPS_L1_CACHE_SHIFT_5
 	default "6" if MIPS_L1_CACHE_SHIFT_6
-- 
1.8.3.2

[PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Florian Fainelli]

Some older machines such as the DECStation use a L1 data-cache shift of
2 (value of 4), add a Kconfig symbol for this value so they can express
this requirement.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
 arch/mips/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 03d0ed3..9ab4239 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1098,6 +1098,9 @@ config FW_SNIPROM
 config BOOT_ELF32
 	bool
 
+config MIPS_L1_CACHE_SHIFT_2
+	bool
+
 config MIPS_L1_CACHE_SHIFT_4
 	bool
 
@@ -1112,6 +1115,7 @@ config MIPS_L1_CACHE_SHIFT_7
 
 config MIPS_L1_CACHE_SHIFT
 	int
+	default "2" if MIPS_L1_CACHE_SHIFT_2
 	default "4" if MIPS_L1_CACHE_SHIFT_4
 	default "5" if MIPS_L1_CACHE_SHIFT_5
 	default "6" if MIPS_L1_CACHE_SHIFT_6
-- 
1.8.3.2

[PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Florian Fainelli]

When support for the DECStation is enabled, it will default to use a
MIPS R3000 class processor. This will cause an intentional build failure
to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
targetting a MIPS R3000 CPU to fix that build failure and satisfy all
requirements.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
 arch/mips/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9ab4239..33738f8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -184,7 +184,8 @@ config MACH_DECSTATION
 	select SYS_SUPPORTS_128HZ
 	select SYS_SUPPORTS_256HZ
 	select SYS_SUPPORTS_1024HZ
-	select MIPS_L1_CACHE_SHIFT_4
+	select MIPS_L1_CACHE_SHIFT_2 if CPU_R3000
+	select MIPS_L1_CACHE_SHIFT_4 if CPU_R4X00
 	help
 	  This enables support for DEC's MIPS based workstations.  For details
 	  see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the
-- 
1.8.3.2

[PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Florian Fainelli]

When support for the DECStation is enabled, it will default to use a
MIPS R3000 class processor. This will cause an intentional build failure
to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
targetting a MIPS R3000 CPU to fix that build failure and satisfy all
requirements.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
 arch/mips/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9ab4239..33738f8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -184,7 +184,8 @@ config MACH_DECSTATION
 	select SYS_SUPPORTS_128HZ
 	select SYS_SUPPORTS_256HZ
 	select SYS_SUPPORTS_1024HZ
-	select MIPS_L1_CACHE_SHIFT_4
+	select MIPS_L1_CACHE_SHIFT_2 if CPU_R3000
+	select MIPS_L1_CACHE_SHIFT_4 if CPU_R4X00
 	help
 	  This enables support for DEC's MIPS based workstations.  For details
 	  see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the
-- 
1.8.3.2

Re: [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Maciej W. Rozycki]

On Tue, 21 Jan 2014, Florian Fainelli wrote:

> When support for the DECStation is enabled, it will default to use a
> MIPS R3000 class processor. This will cause an intentional build failure
> to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
> disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
> targetting a MIPS R3000 CPU to fix that build failure and satisfy all
> requirements.

 Thanks for your contribution.  However I just built a pristine ToT LMO 
kernel for an R3000 DECstation and that went fine, I got no error.  Can 
you provide me with a way to reproduce the problem?

 I am not opposed to your change per se, it may make sense regardless. 
However using a value of MIPS_L1_CACHE_SHIFT that is too high results in 
wasting some memory, but should otherwise be safe I believe, so I'm not 
really convinced adding this config infrastructure is going to pay off.

  Maciej

Re: [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Florian Fainelli]

Le dimanche 23 mars 2014, 02:16:27 Maciej W. Rozycki a écrit :
> On Tue, 21 Jan 2014, Florian Fainelli wrote:
> > When support for the DECStation is enabled, it will default to use a
> > MIPS R3000 class processor. This will cause an intentional build failure
> > to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
> > disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
> > targetting a MIPS R3000 CPU to fix that build failure and satisfy all
> > requirements.
> 
>  Thanks for your contribution.  However I just built a pristine ToT LMO
> kernel for an R3000 DECstation and that went fine, I got no error.  Can
> you provide me with a way to reproduce the problem?

The build failure was only transient, in conjunction wit this patch applied:

http://www.linux-mips.org/archives/linux-mips/2014-01/msg00183.html

which was then reverted.

> 
>  I am not opposed to your change per se, it may make sense regardless.
> However using a value of MIPS_L1_CACHE_SHIFT that is too high results in
> wasting some memory, but should otherwise be safe I believe, so I'm not
> really convinced adding this config infrastructure is going to pay off.

Not quite sure what "infrastructure" you are referring to here.

MIPS_L1_CACHE_SHIFT_<N> is just a bunch of Kconfig symbols that platform can 
select, to avoid an ever-growing list of:

default 5 if MIPS_FOO && MIPS_BAR && MIPS_BAZ

I think that this patch is still applicable as it makes it more accurate which 
L1_CACHE_SHIFT_SIZE is really required for a given CPU configuration 
DECSstation, and will avoid overbooking that value when R3000 CPUs are 
configured/used specifically here.
-- 
Florian

Re: [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Maciej W. Rozycki]

On Tue, 21 Jan 2014, Florian Fainelli wrote:

> When support for the DECStation is enabled, it will default to use a
> MIPS R3000 class processor. This will cause an intentional build failure
> to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
> disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
> targetting a MIPS R3000 CPU to fix that build failure and satisfy all
> requirements.
> 
> Signed-off-by: Florian Fainelli <florian@openwrt.org>

Acked-by: Maciej W. Rozycki <macro@linux-mips.org>

 This actually boots -- Ralf, please apply.

  Maciej

Re: [PATCH 2/2] MIPS: fix DECStation build for L1_CACHE_SHIFT value

[Maciej W. Rozycki]

On Tue, 1 Apr 2014, Maciej W. Rozycki wrote:

> > When support for the DECStation is enabled, it will default to use a
> > MIPS R3000 class processor. This will cause an intentional build failure
> > to popup because MIPS_L1_CACHE_SHIFT and cpu_dcache_line_size()
> > disagree. Fix this by selecting MIPS_L1_CACHE_SHIFT_2 when we build
> > targetting a MIPS R3000 CPU to fix that build failure and satisfy all
> > requirements.
> > 
> > Signed-off-by: Florian Fainelli <florian@openwrt.org>
> 
> Acked-by: Maciej W. Rozycki <macro@linux-mips.org>
> 
>  This actually boots -- Ralf, please apply.

 Having done further investigation I need to withdraw my ack; I see these 
patches went nowhere so far, so please keep the status quo.  The thing is 
while the size of an individual cache entry (i.e. data+tag) is indeed 4 
bytes on the R2000 and R3000 DECstations their cache controllers do not 
necessarily operate on single entries only.  Some models do fills on 
multiple aligned entries at once.  So while the stride of 4 bytes is 
adequate for invalidation, it is not necessarily so for good performance.

 Specifically:

* in DECstation 2100 and 3100 systems [1]:

"The CPU maintains the direct-mapped instruction cache and the 
direct-mapped, write-through data cache.  Each cache is 64 KBytes in 
capacity with a 4-byte line size."

* in DECstation 5000/200 systems [2]:

"The instruction and data caches are configured with a four-word line size 
with loads and stores nominally completing in one cycle.  Instruction and 
data cache fills take advantage of page mode memory cycles to complete a 
four-word fill in 11 access latency cycles, 4 data transfer cycles, plus 
miss and memory latency overhead.  This results in a peak memory read 
bandwidth of 21 MBytes/second with a 25 MHz system clock."

* in DECstation 5000/120, 5000/125 and Personal DECstation 5000/20 and 
  5000/125 systems (CPU daughtercards are interchangeable between these 
  systems) [4]:

"The CPU subsystem contains 64 KB each of instruction cache and data 
cache.  The caches are direct-mapped, write-through caches, each 
containing 16K word entries.  A cache word entry contains 32 bits of 
instruction or data, 13 tag bits, a valid flag bit, and byte-parity bits.  
The tag bits hold the high-order part of the physical address in system 
memory of the cached word.  The low-order bits of the system memory 
address of the cached word are the same as its address in the cache; they 
form the cache index.  The dual cache is implemented in fast SRAM.  The 
R3000A can fetch one instruction and load one data word in each cycle."

* in DECstation 5000/240 systems [3]:

"The caches are direct-mapped, write-through caches, each containing 16K 
word entries.  A cache word entry contains 32 bits of instruction or data, 
16 tag bits, a valid flag bit, and byte-parity bits.  The tag bits hold 
the high-order part of the physical address of the cached word in system 
memory.  The low-order bits of the system memory address of the cached 
word are the same as its address in the cache; they form the cache index. 
(Physically, each cache entry contains a total of 60 bits; the unused bits 
are additional tag and parity bits needed in implementations with smaller 
caches.) [...]

"A cache load fills eight consecutive cache words on an eight-word 
boundary.  The MB contains dual eight-word buffers -- a read buffer and a 
prefetch buffer.  For a cache load, the MB performs a page-mode read from 
memory to fill its read buffer, at one word per 40-ns memory system cycle 
after the 8-cycle page mode read latency.  When the read buffer is full, 
the MB writes the eight locations to cache, in eight 25-ns CPU/cache 
cycles.  When the cache line is on a 16-word boundary, the MB also fills 
the prefetch buffer, so that the next cache line can be available for a 
subsequent cache load without referencing system memory (unless one of the 
prefetched words is invalidated by a processor write to the location)." 

 Our code in r3k_cache_lsize only calculates how many bytes in the cache 
get invalidated at a time.  That's of course useful for optimising cache 
invalidations (that we don't do at the moment anyway), but has nothing to 
do with the optimising for cache prefetches.  A different sizing algorithm 
would have to be used -- not that difficult to invent too, and maybe worth 
adding for informational purposes if nothing else.

 All in all it looks to me like not only MIPS_L1_CACHE_SHIFT_2 shouldn't 
be set for R2000 and R3000 DECstations, but MIPS_L1_CACHE_SHIFT_4 
shouldn't be either.  Instead MIPS_L1_CACHE_SHIFT_6 looks like the right 
choice for good performance with the DECstation 5000/240 system since we 
don't handle individual family members with separate configurations 
(MIPS_L1_CACHE_SHIFT_5 would do for the 5000/200).  R4k DECstations would 
remain using MIPS_L1_CACHE_SHIFT_4, although it is quite possible that the 
MB chip they also have does similar prefetching for their secondary cache 
(there's that mysterious PF bit in its control and status register).

 References:

[1] Workstation Systems Engineering: "DECstation 3100 Desktop Workstation 
    Functional Specification", Revision 1.3, August 28, 1990, Digital 
    Equipment Corporation, section 6.1: "Processor", p. 4.

[2] Workstation Systems Engineering: "DECstation 5000/200 KN02 System 
    Module Functional Specification", Revision 1.3, August 27, 1990, 
    Digital Equipment Corporation, section 4.3: "Processor Subsystem", p. 
    4.

[3] Worksystems Base Product Marketing: "Personal DECstation Series 
    Technical Overview", Version 1.0, December, 1991, Digital Equipment 
    Corporation, section 2.2.3: "The Personal DECstation 5000 CPU 
    Subsystem", p. 8.

[4] Worksystems Base Product Marketing: "DECstation 5000 Model 240 
    Workstation Technical Overview", Version 1.0, December, 1991, Digital 
    Equipment Corporation, section 2.2.4: "Cache Architecture, 
    Implementation, and Operation", pp. 8-9.

  Maciej

Re: [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Ralf Baechle]

On Tue, Jan 21, 2014 at 10:01:33AM -0800, Florian Fainelli wrote:

> Some older machines such as the DECStation use a L1 data-cache shift of
> 2 (value of 4), add a Kconfig symbol for this value so they can express
> this requirement.

Older DECstations got R2000/R3000 processors which have 16 byte cache
lines.  So a cache shift value of 4 would appear to be right.  Maciej?

  Ralf

Re: [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Maciej W. Rozycki]

On Mon, 24 Mar 2014, Ralf Baechle wrote:

> > Some older machines such as the DECStation use a L1 data-cache shift of
> > 2 (value of 4), add a Kconfig symbol for this value so they can express
> > this requirement.
> 
> Older DECstations got R2000/R3000 processors which have 16 byte cache
> lines.  So a cache shift value of 4 would appear to be right.  Maciej?

 Nope:

This is a DECstation 5000/1xx
CPU revision is: 00000230 (R3000A)
FPU revision is: 00000340
[...]
Primary instruction cache 64kB, linesize 4 bytes.
Primary data cache 128kB, linesize 4 bytes.

or:

This is a DECstation 5000/2x0
CPU revision is: 00000230
FPU revision is: 00000340
[...]
Primary instruction cache 64kB, linesize 4 bytes.
Primary data cache 64kB, linesize 4 bytes.

or:

This is a DECstation 5000/200
CPU revision is: 00000220
FPU revision is: 00000320
[...]
Primary instruction cache 64kB, linesize 4 bytes.
Primary data cache 64kB, linesize 4 bytes.

or even:

This is a DECstation 2100/3100
CPU revision is: 00000220
FPU revision is: 00000320
[...]
Primary instruction cache 64kB, linesize 4 bytes.
Primary data cache 64kB, linesize 4 bytes.

-- so it looks like it's consistent 4 bytes across all the variations 
(there's also a /1xx variant with 64kB D$ that I don't have a log from, 
but it has the same line size AFAIK).

  Maciej

Re: [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Florian Fainelli]

2014-03-24 9:20 GMT-07:00 Maciej W. Rozycki <macro@linux-mips.org>:
> On Mon, 24 Mar 2014, Ralf Baechle wrote:
>
>> > Some older machines such as the DECStation use a L1 data-cache shift of
>> > 2 (value of 4), add a Kconfig symbol for this value so they can express
>> > this requirement.
>>
>> Older DECstations got R2000/R3000 processors which have 16 byte cache
>> lines.  So a cache shift value of 4 would appear to be right.  Maciej?

I used arch/mips/include/asm/mach-dec/cpu-feature-overrides.h as a
reference and it does look consistent with your boot log snippets
(assuming those are only for R2k/R3k processors and not R4k ones?)

>
>  Nope:
>
> This is a DECstation 5000/1xx
> CPU revision is: 00000230 (R3000A)
> FPU revision is: 00000340
> [...]
> Primary instruction cache 64kB, linesize 4 bytes.
> Primary data cache 128kB, linesize 4 bytes.
>
> or:
>
> This is a DECstation 5000/2x0
> CPU revision is: 00000230
> FPU revision is: 00000340
> [...]
> Primary instruction cache 64kB, linesize 4 bytes.
> Primary data cache 64kB, linesize 4 bytes.
>
> or:
>
> This is a DECstation 5000/200
> CPU revision is: 00000220
> FPU revision is: 00000320
> [...]
> Primary instruction cache 64kB, linesize 4 bytes.
> Primary data cache 64kB, linesize 4 bytes.
>
> or even:
>
> This is a DECstation 2100/3100
> CPU revision is: 00000220
> FPU revision is: 00000320
> [...]
> Primary instruction cache 64kB, linesize 4 bytes.
> Primary data cache 64kB, linesize 4 bytes.
>
> -- so it looks like it's consistent 4 bytes across all the variations
> (there's also a /1xx variant with 64kB D$ that I don't have a log from,
> but it has the same line size AFAIK).

-- 
Florian

Re: [PATCH 1/2] MIPS: add MIPS_L1_CACHE_SHIFT_2

[Maciej W. Rozycki]

On Tue, 21 Jan 2014, Florian Fainelli wrote:

> Some older machines such as the DECStation use a L1 data-cache shift of
> 2 (value of 4), add a Kconfig symbol for this value so they can express
> this requirement.
> 
> Signed-off-by: Florian Fainelli <florian@openwrt.org>

Acked-by: Maciej W. Rozycki <macro@linux-mips.org>

 This actually boots -- Ralf, please apply.

  Maciej