ARM: vfp: ensure VFP_arch is non-zero when VFP is not supported

Commit d3f79584a8b5 ("ARM: cleanup undefined instruction entry code")
improved the register scheduling when handling undefined instructions.
A side effect of this is that r5 is now used as a temporary, whilst the
VFP probing code relies on r5 containing a non-zero value when VFP is
not supported.

This patch fixes the VFP detection code so that we don't rely on the
contents of r5. Without this patch, Linux dies loudly on CPUs without
VFP support.

Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: entry: allow ARM-private syscalls to be restarted

System calls will only be restarted after signal handling if they (a)
return an error code indicating that a restart is required and (b) have
`why' set to a non-zero value, to indicate that the signal interrupted
them.

This patch leaves `why' set to a non-zero value for ARM-private syscalls
, and only zeroes it for syscalls that are not implemented.

Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: mm: remove redundant dsb() prior to range TLB invalidation

The kernel TLB range invalidation functions already contain dsb
instructions before and after the maintenance, so there is no need to
introduce additional barriers.

Signed-off-by: Will Deacon <will.deacon@arm.com>

Conflicts:

	arch/arm/mm/dma-mapping.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
ARM: barrier: allow options to be passed to memory barrier instructions

On ARMv7, the memory barrier instructions take an optional `option'
field which can be used to constrain the effects of a memory barrier
based on shareability and access type.

This patch allows the caller to pass these options if required, and
updates the smp_*() barriers to request inner-shareable barriers,
affecting only stores for the _wmb variant. wmb() is also changed to
use the -st version of dsb.

Reported-by: Albin Tonnerre <albin.tonnerre@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead

Many ARMv7 cores have hardware page table walkers that can read the L1
cache. This is discoverable from the ID_MMFR3 register, although this
can be expensive to access from the low-level set_pte functions and is a
pain to cache, particularly with multi-cluster systems.

A useful observation is that the multi-processing extensions for ARMv7
require coherent table walks, meaning that we can make use of ALT_SMP
patching in proc-v7-* to patch away the cache flush safely for these
cores.

Reported-by: Albin Tonnerre <Albin.Tonnerre@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/include/asm/tlbflush.h

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
ARM: mm: use inner-shareable barriers for TLB and user cache operations

System-wide barriers aren't required for situations where we only need
to make visibility and ordering guarantees in the inner-shareable domain
(i.e. we are not dealing with devices or potentially incoherent CPUs).

This patch changes the v7 TLB operations, coherent_user_range and
dcache_clean_area functions to user inner-shareable barriers. For cache
maintenance, only the store access type is required to ensure completion.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
mm: decrease default dirty ratio

The default dirty ratio is chosen to be a compromise between throughput and
overall system latency. On a desktop, if an application writes to disk a lot,
that application should be the one to slow down rather than the desktop as a
whole. At higher dirty ratio settings, an application could write a lot to
disk and then happily use lots of CPU time after that while the rest of the
system is busy waiting on that naughty application's disk writes to complete
before anything else happening.

Lower ratios mean that the application that do a lot of disk writes end up
being responsible for their own actions and they're the ones that slow down
rather than the system in general.

This does decrease overall write throughput, but to the benefit of the latency
of the system as a whole with disk writes.

Other checks may well round this up to 10 still at startup.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm : drop swap cache aggressively

While it may be nice to have a copy of pages on swap once written there, the
more garbage we leave in the swapspace the slower any further writes and
reads to and from it are. Just free swapcache whenever we can.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: kswapd inherit prio

When kswapd is awoken due to reclaim by a running task, set the priority of
kswapd to that of the calling task thus making memory reclaim cpu activity
affected by nice level.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mm: minimal swappiness

I've yet to find any desktop workload that benefits from anything higher than
a swappiness as low as possible. Unfortunately setting it to zero can rarely
lead to unexplained stalls in the VM so use 10.

-ck
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
d2: defconfig: fix error

-don't know how long that's been there
Signed-off-by: Luis Cruz <ljc2491@gmail.com>