<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/arch/arc/lib/cache.c, branch v2018.01</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>ARC: cache: explicitly initialize "*_exists" variables</title>
<updated>2017-12-11T08:36:22+00:00</updated>
<author>
<name>Eugeniy Paltsev</name>
<email>Eugeniy.Paltsev@synopsys.com</email>
</author>
<published>2017-11-30T14:41:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3cf239394a5ca3ada68c683ef5d19e16f9bfd170'/>
<id>3cf239394a5ca3ada68c683ef5d19e16f9bfd170</id>
<content type='text'>
dcache_exists, icache_exists, slc_exists and ioc_exists global
variables in "arch/arc/lib/cache.c" remain uninitialized if
SoC doesn't have corresponding HW.

This happens because we use the next constructions for their
definition and initialization:
--------------------------&gt;&gt;---------------------
int ioc_exists __section(".data");

if (/* condition */)
		ioc_exists = 1;
--------------------------&gt;&gt;---------------------

That's quite a non-trivial issue as one may think of it.
The point is we intentionally put those variables in ".data" section
so they might survive relocation (remember we initilaize them very early
before relocation and continue to use after reloaction). While being
non-initialized and not explicitly put in .data section they would end-up
in ".bss" section which by definition is filled with zeroes.
But since we place those variables in .data section we need to care
about their proper initialization ourselves.

Also while at it we change their type to "bool" as more appropriate.

Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
dcache_exists, icache_exists, slc_exists and ioc_exists global
variables in "arch/arc/lib/cache.c" remain uninitialized if
SoC doesn't have corresponding HW.

This happens because we use the next constructions for their
definition and initialization:
--------------------------&gt;&gt;---------------------
int ioc_exists __section(".data");

if (/* condition */)
		ioc_exists = 1;
--------------------------&gt;&gt;---------------------

That's quite a non-trivial issue as one may think of it.
The point is we intentionally put those variables in ".data" section
so they might survive relocation (remember we initilaize them very early
before relocation and continue to use after reloaction). While being
non-initialized and not explicitly put in .data section they would end-up
in ".bss" section which by definition is filled with zeroes.
But since we place those variables in .data section we need to care
about their proper initialization ourselves.

Also while at it we change their type to "bool" as more appropriate.

Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: cache: Add required NOPs after invalidation of instruction cache</title>
<updated>2017-11-24T16:38:23+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2017-11-17T13:02:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f2a226780fa0e4055bec636b8108bf7e80951174'/>
<id>f2a226780fa0e4055bec636b8108bf7e80951174</id>
<content type='text'>
As per ARC HS databook (see chapter 5.3.3.2) it is required to add
3 NOPs after each write to IC_IVIC which we do from now on.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Eugeniy Paltsev &lt;paltsev@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As per ARC HS databook (see chapter 5.3.3.2) it is required to add
3 NOPs after each write to IC_IVIC which we do from now on.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Cc: Eugeniy Paltsev &lt;paltsev@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arcv2: Set IOC aperture so it covers available DDR</title>
<updated>2017-06-29T16:34:10+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2017-06-26T08:46:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=97a63144a906827ad7e3c4ef18d641c2765b1ebc'/>
<id>97a63144a906827ad7e3c4ef18d641c2765b1ebc</id>
<content type='text'>
We used to use the same memory layout and size for a couple of
boards and thus we just hardcoding IOC aperture start and size.

Now when we're getting more boards with more memory on board we
need to have an ability to set IOC so it matches real DDR layout
and size.

Even though it is not really a must but for simplicity we assume
IOC covers all the DDR we have, that gives us a chance to not
bother where DMA buffers are allocated - any part of DDR is OK.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We used to use the same memory layout and size for a couple of
boards and thus we just hardcoding IOC aperture start and size.

Now when we're getting more boards with more memory on board we
need to have an ability to set IOC so it matches real DDR layout
and size.

Even though it is not really a must but for simplicity we assume
IOC covers all the DDR we have, that gives us a chance to not
bother where DMA buffers are allocated - any part of DDR is OK.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARCv2: SLC: Make sure busy bit is set properly on SLC flushing</title>
<updated>2017-04-11T14:54:31+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2017-04-05T14:50:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=40a808f173008729a0c631ab84693b6a2b0dcfc9'/>
<id>40a808f173008729a0c631ab84693b6a2b0dcfc9</id>
<content type='text'>
As reported in STAR 9001165532, an SLC control reg read (for checking
busy state) right after SLC invalidate command may incorrectly return
NOT busy causing software to NOT spin-wait while operation is underway.
(and for some reason this only happens if L1 cache is also disabled - as
required by IOC programming model)

Suggested workaround is to do an additional Control Reg read, which
ensures the 2nd read gets the right status.

Same fix made in Linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70c473396cbdec1168a6eff60e13029c0916854

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As reported in STAR 9001165532, an SLC control reg read (for checking
busy state) right after SLC invalidate command may incorrectly return
NOT busy causing software to NOT spin-wait while operation is underway.
(and for some reason this only happens if L1 cache is also disabled - as
required by IOC programming model)

Suggested workaround is to do an additional Control Reg read, which
ensures the 2nd read gets the right status.

Same fix made in Linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70c473396cbdec1168a6eff60e13029c0916854

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc/cache: Flush &amp; invalidate all caches right before enabling IOC</title>
<updated>2016-06-13T12:38:05+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2016-06-08T05:04:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a4a43fcf9cca1ebd3d26f9a01b923b7393d69c54'/>
<id>a4a43fcf9cca1ebd3d26f9a01b923b7393d69c54</id>
<content type='text'>
According to ARC HS databook it is required to flush and disable
caches prior programming IOC registers. Otherwise ongoing coherent
memory operations may not observe the coherency protocols as
expected.

But since in ARC HS v2.1 there's no way to disable SLC (AKA L2 cache)
we're doing our best flushing and invalidating it.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
According to ARC HS databook it is required to flush and disable
caches prior programming IOC registers. Otherwise ongoing coherent
memory operations may not observe the coherency protocols as
expected.

But since in ARC HS v2.1 there's no way to disable SLC (AKA L2 cache)
we're doing our best flushing and invalidating it.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc/cache: really do invalidate_dcache_all() even if IOC exists</title>
<updated>2016-06-13T12:38:05+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2016-06-08T04:57:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=bd91508b50ade5c73b3749bf4e5ede31d2da7ef8'/>
<id>bd91508b50ade5c73b3749bf4e5ede31d2da7ef8</id>
<content type='text'>
invalidate_dcache_all() could be used in different use-cases
and what is especially important most of those cases won't be
related to DMAed data to or from peripherals, i.e. we'll be doing
invalidation of data used purely by CPU cores.

Given that IOC engine only snoops data that goes through DMA
we need to care ourselves about data used only by CPU cores
and so remove dependency on IOC from invalidate_dcache_all()
and always do real invalidation.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
invalidate_dcache_all() could be used in different use-cases
and what is especially important most of those cases won't be
related to DMAed data to or from peripherals, i.e. we'll be doing
invalidation of data used purely by CPU cores.

Given that IOC engine only snoops data that goes through DMA
we need to care ourselves about data used only by CPU cores
and so remove dependency on IOC from invalidate_dcache_all()
and always do real invalidation.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc/cache: really do flush_dcache_all() even if IOC exists</title>
<updated>2016-04-21T17:09:59+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>abrodkin@synopsys.com</email>
</author>
<published>2016-04-16T12:28:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2a8382c6fe7ddf0e15791b3ffa5f390a674a212b'/>
<id>2a8382c6fe7ddf0e15791b3ffa5f390a674a212b</id>
<content type='text'>
flush_dcache_all() is used in the very end of U-Boot self relocation
to write back all copied and then patched code and data to their
new location in the very end of available memory space.

Since that has nothing to do with IO (i.e. no external DMA happens
here) IOC won't help here and we need to write back data cache contents
manually.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
flush_dcache_all() is used in the very end of U-Boot self relocation
to write back all copied and then patched code and data to their
new location in the very end of available memory space.

Since that has nothing to do with IO (i.e. no external DMA happens
here) IOC won't help here and we need to write back data cache contents
manually.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: cache - utilize IO coherency (AKA IOC) engine</title>
<updated>2016-02-20T08:20:05+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-12-14T14:15:13+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=db6ce2312dcae87619136457d1f9df56789f630a'/>
<id>db6ce2312dcae87619136457d1f9df56789f630a</id>
<content type='text'>
With release of ARC HS38 v2.1 new IO coherency engine could be built-in
ARC core. This hardware module ensures coherency between DMA-ed data
from peripherals and L2 cache.

With L2 and IOC enabled there's no overhead for L2 cache manual
maintenance which results in significantly improved IO bandwidth.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With release of ARC HS38 v2.1 new IO coherency engine could be built-in
ARC core. This hardware module ensures coherency between DMA-ed data
from peripherals and L2 cache.

With L2 and IOC enabled there's no overhead for L2 cache manual
maintenance which results in significantly improved IO bandwidth.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: cache - accommodate different L1 cache line lengths</title>
<updated>2016-02-20T08:19:53+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-12-14T14:14:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=379b3280b30c4aad5ff0fdf1cd6431c5fa6861b1'/>
<id>379b3280b30c4aad5ff0fdf1cd6431c5fa6861b1</id>
<content type='text'>
ARC core could be configured with different L1 and L2 (AKA SLC) cache
line lengths. At least these values are possible and were really used:
32, 64 or 128 bytes.

Current implementation requires cache line to be selected upon U-Boot
configuration and then it will only work on matching hardware. Indeed
this is quite efficient because cache line length gets hardcoded during
code compilation. But OTOH it makes binary less portable.

With this commit we allow U-Boot to determine real L1 cache line length
early in runtime and use this value later on. This extends portability
of U-Boot binary a lot.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ARC core could be configured with different L1 and L2 (AKA SLC) cache
line lengths. At least these values are possible and were really used:
32, 64 or 128 bytes.

Current implementation requires cache line to be selected upon U-Boot
configuration and then it will only work on matching hardware. Indeed
this is quite efficient because cache line length gets hardcoded during
code compilation. But OTOH it makes binary less portable.

With this commit we allow U-Boot to determine real L1 cache line length
early in runtime and use this value later on. This extends portability
of U-Boot binary a lot.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arc: significant cache rework</title>
<updated>2015-07-01T14:17:27+00:00</updated>
<author>
<name>Alexey Brodkin</name>
<email>Alexey.Brodkin@synopsys.com</email>
</author>
<published>2015-05-18T13:56:26+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ef639e6f7076c19959f40f367cead5108d099592'/>
<id>ef639e6f7076c19959f40f367cead5108d099592</id>
<content type='text'>
[1] Align cache management functions to those in Linux kernel. I.e.:
    a) Use the same functions for all cache ops (D$ Inv/Flush)
    b) Split cache ops in 3 sub-functions: "before", "lineloop" and
"after". That way we may re-use "before" and "after" functions for
region and full cache ops.

 [2] Implement full-functional L2 (SLC) management. Before SLC was
simply disabled early on boot. It's also possible to enable or disable
L2 cache from config utility.

 [3] Disable/enable corresponding caches early on boot. So if U-Boot is
configured to use caches they will be used at all times (this is useful
in partucular for speed-up of relocation).

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[1] Align cache management functions to those in Linux kernel. I.e.:
    a) Use the same functions for all cache ops (D$ Inv/Flush)
    b) Split cache ops in 3 sub-functions: "before", "lineloop" and
"after". That way we may re-use "before" and "after" functions for
region and full cache ops.

 [2] Implement full-functional L2 (SLC) management. Before SLC was
simply disabled early on boot. It's also possible to enable or disable
L2 cache from config utility.

 [3] Disable/enable corresponding caches early on boot. So if U-Boot is
configured to use caches they will be used at all times (this is useful
in partucular for speed-up of relocation).

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
