linux-toradex.git/arch/arc/include/asm/cacheflush.h, branch v4.4.85

ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache

2017-01-09T07:07:48+00:00

commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.

An ARC700 customer reported linux boot crashes when upgrading to bigger
L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
current code only assumed 2 colours, while theirs had 4. So default to 4
colours and complain if there are fewer. Ideally this needs to be a
Kconfig option, but heck that's too much of hassle for a single user.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: mm: PAE40: switch to using phys_addr_t for physical addresses

2015-10-28T14:20:29+00:00

That way a single flip of phys_addr_t to 64 bit ensures all places
dealing with physical addresses get correct data

Signed-off-by: Vineet Gupta

ARC: fold ___flush_dcache_page into __flush_dcache_page

2015-05-19T05:57:13+00:00

Signed-off-by: Vineet Gupta

ARC: [mm] Assume pagecache page dirty by default

2013-06-22T13:53:19+00:00

Similar to ARM/SH

Signed-off-by: Vineet Gupta

ARC: cache detection code bitrot

2013-06-22T08:16:43+00:00

* Number of (i|d)cache ways can be retrieved from BCRs and hence no need
  to cross check with with built-in constants
* Use of IS_ENABLED() to check for a Kconfig option
* is_not_cache_aligned() not used anymore

Signed-off-by: Vineet Gupta

ARC: Use enough bits for determining page's cache color

2013-05-23T08:55:09+00:00

The current code uses 2 bits for determining page's dcache color, thus
sorting pages into 4 bins, whereas the aliasing dcache really has 2 bins
(8k page, 64k dcache - 4 way-set-assoc).
This can cause extraneous flushes - e.g. color 0 and 2.

Signed-off-by: Vineet Gupta

ARC: Brown paper bag bug in macro for checking cache color

2013-05-23T08:54:52+00:00

The VM_EXEC check in update_mmu_cache() was getting optimized away
because of a stupid error in definition of macro addr_not_cache_congruent()

The intention was to have the equivalent of following:

	if (a || (1 ? b : 0))

but we ended up with following:

	if (a || 1 ? b : 0)

And because precedence of '||' is more that that of '?', gcc was optimizing
away evaluation of 

Nasty Repercussions:
1. For non-aliasing configs it would mean some extraneous dcache flushes
   for non-code pages if U/K mappings were not congruent.
2. For aliasing config, some needed dcache flush for code pages might
   be missed if U/K mappings were congruent.

Signed-off-by: Vineet Gupta

ARC: [mm] Aliasing VIPT dcache support 4/4

2013-05-09T16:30:57+00:00

Enforce congruency of userspace shared mappings

Signed-off-by: Vineet Gupta

ARC: [mm] Aliasing VIPT dcache support 3/4

2013-05-09T16:30:57+00:00

Fix the one zillion warnings

Signed-off-by: Vineet Gupta

ARC: [mm] Aliasing VIPT dcache support 2/4

2013-05-09T16:29:46+00:00

This is the meat of the series which prevents any dcache alias creation
by always keeping the U and K mapping of a page congruent.
If a mapping already exists, and other tries to access the page, prev
one is flushed to physical page (wback+inv)

Essentially flush_dcache_page()/copy_user_highpage() create K-mapping
of a page, but try to defer flushing, unless U-mapping exist.
When page is actually mapped to userspace, update_mmu_cache() flushes
the K-mapping (in certain cases this can be optimised out)

Additonally flush_cache_mm(), flush_cache_range(), flush_cache_page()
handle the puring of stale userspace mappings on exit/munmap...

flush_anon_page() handles the existing U-mapping for anon page before
kernel reads it via the GUP path.

Note that while not complete, this is enough to boot a simple
dynamically linked Busybox based rootfs

Signed-off-by: Vineet Gupta